GI Jimbo

The work-around I've been using is to list the variables under Externals instead. I know this doesn't work in all situations since every FB instance uses the same externals but I've been able to get by with it.

It's really strange to me that the error mentions STRING type because I'm not even using a string. I get the error even when I try a single BOOL IN_OUT variable. I just created a test FB with a single line: InOutBit := TRUE; It actually compiles without complaining before I create an instance of the FB. However once I create an instance and link a bool to the IN_OUT variable, then the error shows up. Edit: What's really even more strange is that if I delete that instance of the FB, the error still persists. I deleted the rung and the FB symbol that's created for it. I actually had to delete the FB altogether to get the error to go away.

I'm using CX-Programmer (currently version 9.86) to program a CP1H XA unit version 1.2. Per everything I can see in the documentation for the PLC and Function Block Structured Text (W451-E1-03 & W447-E1-18), it appears I should be able to use IN_OUT variables. However, any time I add one to a function block, I get an error when compiling: "ERROR: STRING type or an Input Output variable is not supported by the PLC of this unit version. Check the unit version in program check options.". I've tried going to Program > Program Check Options and trying all of the available unit versions (1.0, 1.1, and 1.3) but the error still persists. Is this a bug or am I missing something? I appreciate any help that anyone is willing to provide.

Ah, I hadn't seen the "Message Display" functionality of the labels yet. I think this might be the way I go. Thanks again @IO_Rack for all your help!

Thanks! What version can/should I convert the project to? Would I be safe in assuming I could go as high as my system version of 8.41?

I have an NS8-TV00-V2 System version 8.41 Project data version 4.00 I'm trying to make a button that achieves the following: Toggle a value by incrementing (like a word button with values 0, 1, & 2) Changes color depending on the value (like a word lamp) Changes label depending on the value It sounds like a multi-function button is what I'd need but it's greyed out. I can almost achieve this with a word button and word lamp but still can't get the label changing feature. The word lamp's label tab seems to have an option to "switch label according to the address value" but that option is greyed out as well. I'm guessing this is a version issue? Is it possible to upgrade the firmware of an NS8-TV00-V2? Thanks in advance for any help you can provide!

@chelton wow! That was very helpful and insightful. The CP1H wasn't listed in that manual but its information was WAY more helpful that what I'd found in the manuals for the CP1H. Especially the examples. 👍 That said, I really don't know why the application I'm working on would need to use background processing for strings so I turned it off. Now, suddenly everything string related seems to be working as expected. I REALLY appreciate your and @IO_Rack's help.

@chelton Yes, it is turned on.

Sorry, one more post and then I'll wait for a response. I got curious and tried MOV$ with the empty string instead of CLR$ to see how it would compare time-wise. It actually made quite a difference. It takes between 6 and 9 cycles with the MOV$ EmptyStr vs the 9 to 13 with CLR$. 🤔

Sorry for all the consecutive posting but I have another test update. I decided to write the code so each of the reset rungs runs until its corresponding string is cleared (equal to a null string). I also added an integer that increments every cycle so I can see how many cycles it takes. You can look over my code below if you're interested in how I did it but the result is that it varies between 9 and 13 cycles at about 4.0-5.0 ms mean cycle time. The code:

I also verified just now that if I make the first CLR$ never execute, it does reset the second string but not the third. So it definitely still seems like it's only able to process one string instruction at a time and just ignores the rest. 🫤

Thanks for the replies guys. @chelton I tried your suggestion of using SET and RSET on the ATestReset symbol and got the same results. I can toggle the bit on again and again but the last two strings just keep their old values and don't clear. @IO_Rack The next thing I tried was creating two new bits that I'm using SET and RSET on in each of the resetting rungs. Each one looks like this but sets the next bit and resets the current one: Unfortunately the result is still the same.

@IO_Rack Thank you for your response. Each of the 3 string variables/symbols are being referenced in 3 places. Where they're supposed to be reset A downward differentiated rung (when the TCP receive request bit turns off). The rung calls a DEL$ instruction to remove the last character (CR). A downward differentiated rung (when the TCP close request bit turns off). The rung calls an FVAL instruction to convert the string to a float. The ACapResult symbol you see in my last post coincides with the ACapReturnStr. If I make the TCP communications never trigger, cases 2 & 3 never happen but still only the first of my 3 CLR$ instructions complete. I checked the addresses of all 3 string symbols and nothing else references any of the word addresses in their memory space (D10340, D10360, D10380). In the symbols table they're all STRING(39) so 20 words of space between them should be sufficient. I used 39 characters for the strings instead of 40 because I wasn't sure if CX-Programmer used one of the allocated bytes for a null terminator or not so I left a null character between each. Here's a screenshot of the data memory with some values before the reset gets triggered. Here's the data memory after triggering the reset. Edit: Here's the Cross-Reference screen shot.

My current example is as follows: I'm using a reset bit to try and trigger a set of variables to be cleared/reset. This bit is only true for one cycle so it really doesn't matter if I use upward differentiated CLR$ or not. And I have three rungs pretty much identical to the following (with different symbols of course) where the variables should be cleared: I've been able to address this at times by setting latches around the individual string instructions until a set number of cycles has passed or a set amount of time has passed. A solution like that just seems ridiculous to me. Why wouldn't the string functions have done bits?

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?