GI Jimbo

I've been working with (or trying to work with) string instructions for days and I'm coming to the conclusion that the CP1H can't handle more than one string instruction per rung. Even something as basic as CLR$. Here's and example: I have a rung that is supposed to reset 3 float (REAL) values and 3 string values. I'm using upward differentiated MOVL instructions to reset the float values and they work every time beautifully. At first I tried upward differentiated CLR$ instructions but when that didn't work I went to the "normal" run-when-true form. It doesn't seem to make a difference. It only resets/clears the first string. I even added a timer latch, set it at 1 second, and it still won't clear the other two strings. The string instructions tend to run as expected when I use the simulator but any time I try to run them on the controller, inevitably many of them don't seem to want to trigger. If they take excessive time to run, why isn't there a "done bit" available so you can make them run sequentially?

Well it seems that this isn't related to the sub-routine or the timing. I set up some test logic at the beginning of my program and gave it a timer of 10 seconds to complete the RGHT$ operation and still nothing. I created an output to get triggered if there's an error code and found that it is getting triggered. Per the CP1H programming manual, the ER flag is: ON if more than 4,095 characters are designated by S1. This certainly isn't the case as the LEN$ function run right before is returning 31 characters. ON if more than 4,095 characters (0FFF hex) are designated by S2. This certainly isn't the case as the destination address has 49 characters available and is full of zeros/NULLs. ON if the Communications Port Enabled Flag for the communications port number specified as the Com Port number for Background Execution is OFF when background processing is specified (CP1H only). I have no idea what this is. I tried searching the manual for "Background Execution" and only got results in each of the string function error code possibilities. Would someone be able to point me in the right direction here? OFF in all other cases.

For a little more context, I've been trying to complete this operation in a sub-routine (SBN). I tried running the functions outside of the sub-routine and found that MOV$ completed if its input was the P_On (always-on) contact. This leads me to think that my sub-routine must not be allowing enough time/cycles for the RGHT and/or MOV operations. This leads me to another question. How do you ensure that just enough time is given to RGHT or MOV operations before moving to the next operation which depends on their completion? Typically I'd expect there to be some sort of done bit for operations that do not complete immediately. From what I see in the instruction help, there doesn't appear to be one. However, the ER and '=' flags are mentioned. The instructions state that the '=' flag will be on if #0000 is output to D. If I add a contact/condition dependent on the '=' flag not being on, will this effectively act as a done bit? Thanks in advance for any responses. I'm an Omron newbie so any guidance is appreciated.

Sorry for the double post, I got an error when I tried to edit. I even tried to use MOV$ D10300 D1020 and it's still not copying.

I have a string of ASCII characters stored in location D10300. I used LEN$ to get the number of characters (31 or #001F). However, when I try to use RGHT$ D10300 #001F D1020, nothing is being copied to D1020. Any ideas as to what might be the problem? There's plenty of room at/after D1020 to contain the 31 characters + #00 or #0000 null terminator. Any help is appreciated.

Sorry for the necro post but I've found it very hard to find much help online for Omron and this thread matches my problem almost exactly. @strantor_ Like you, I'm VERY frustrated that this limitation isn't explicitly stated anywhere in the multitude of Omron's reference documents. Would you please elaborate a little more about how you did this? I tried changing my STRING in-out variable to a WORD and still have issues because the data/string length is much bigger than a WORD. Was the string you were passing to the FB just 1 or 2 characters? Mine can be up to 30 characters (15 WORDs or 240 bits) which is much longer than the largest other option which is an LWORD (64 bits or 8 characters). I'd assume the last character would have to be NULL too so that would be 7 usable characters at most. I considered writing logic to copy the string to an array of LWORDs but that's about as complicated as what I want to use the FB for in the first place (extract a sub-string and convert it to a real/float). For the moment I think I'm just going to abandon the FB and use a sub-routine instead. The way I understand it, Omron FB in-out variables are effectively pass-by-reference. It's hard for me to understand why the CP1H function blocks wouldn't be able to take pass-by-ref strings if they're capable of working with string variables internally. Is it because of the variable length of strings? But if that's the case, why couldn't they just require you to pass the length as an int in addition to the string address?