Slc500/03 instruction not supported.

Newbie question. I have 2 machines that are almost identical. Programmed a counter and added a cmore micro hmi. I needed floating point math. 1 machine has 5/03 with os300. I had an os upgrade putting up to os301. That machine my counter works fine. The 2nd machine has the L532E 5/03 with os302 version C. For one reason I get a processor does not support this instruction.

I am adding an integer to a float and placing the result in a float. It seems to work fine on the first machine? (If I'm wrong about it please tell me) But on the s302 c it gives an error. I even tried a test program with no other code to verify it wasn't due to the code I was modifying or configuration. I even tried the compute instruction and tried Move... Same thing.

I did try specifying a lower os version while offline. Plain os302 processor L532C/D. I was then able to verify the project. Although it asks to resize data tables. Then I set the processor/version back and it then verified ok. So I'm just looking for input on why I get that error.

It appears the code works on the Plc but I am having com problems with the cmore panel. If anyone wants to chime in on that it'd be great. Going to call automation direct support Friday when I have access to the machine off production. I'm wondering if the resizing affected communication. I can't see it being a different os since it's standard dh438. On a side note the first machine has a rio scanner with 4 units. The g config has 4 1/4 racks in a logical rack. The problem machine has 3 1/4 racks. Maybe com problems dues the addressing boundary issues? The exact error is a PLC COM TIME OUT.

Thanks in advance for anyone's input!

"Instruction Not Supported". Are you trying to use the CPT (Compute) instruction? If so, you may be able to break up the math into multiple individual steps (if the CPT instruction is what is not supported).

If your controller allowed you to add floating point registers, then it wil support floating point math. It may not, however, allow the use of the CPT instruction. It has been so long since I used those older firmware version, I do not recall the details of what has been added to what models over the years. ADD, DIV, MUL, SUB should all still work as expected as long as the result is targeted at a "float" or real number.

About the "resize data tables"... Any time you change controller properties in RSLogix500, the software will offer to do this for you. I rarely find it useful, and normally uncheck that option. If you "shrunk" a data table and an address that is sought by the HMI is now missing, that could explain your error.

I recently battled a firmware problem with the C-more evil uncle the EZAutomation Windows CE series in which their DH485 driver is simply broken. I got the same error you describe after doing a firmware update (required by my newer version of the editor software). This is a different product and the two may not actually be blood relatives for all I know after the bloody divorce between the two companies. I am just throwing this out there just in case you rule out everything else. I got past the problem by contacting tech support who gave me several options to try before finally giving me a link to an older version of the editor software and older firmware which did not have the bug.

What exact instruction gives you the 'not supported' message ?

Is it literally the ADD instruction with mixed N and F datatypes ?

An OS300 controller will not support a handful of things that were added in OS301 and OS302. If you have upgraded the controller, you need to set the controller model in RSLogix 500 to match the new firmware.

Does the C-More tell you anything about exactly which addresses it is trying to read when it times out ?

If the C-More is trying to directly read the Input or Output data tables it might make a difference which hardware you have. The difference in the RIO tables should not matter.

Thanks guys

Ken. It is any instruction using mixed data types. I tried add cpt mov... Os is 302 ver C processor L532E But when using os302 older version not listed. Older processor L532C/D it verifies fine. Strange. No upgrade done on that processor.

I agree with the direct reading of inputs/outputs theory. Especially since I did resize data tables since I specified the older processor. Complied ok. Then respecified the original processor to get a good verify. Strange how it compiled ok with an older processor and then after restoring it to the newer one it compiles with no error.

Okie. The instructions are supported but give the error with the mixed types. Not just cpt but also add and even just mov an n to an f. I also suspect the possibility of a data table resize being the problem as you said. My cmore panels are both the same version and the software matches. AD says you need the proper software version for the panel version. That's ok. But maybe the dh438 driver that works on the os301 doesn't work with the os302.

A big problem of course is the machine is always in production except Friday's. Production gets the jitters every time I ask for just a 2 minute Plc upload! Makes it tough to try different approaches...

Hey thanks again guys.

I recall running into this before, too. If memory serves me, try COPying the integer(s) into float(s) instead ov MOVing, then use the floats exclusively in the calculation. I think the problem was on a 503 with very old firmware, but I could be mistaken.

Thanks rg

I forget if I tried that yet. But from what I've read here and there that the mov will convert before moving. I heard that the cop instruction just copies the exact binary data from one address to another. I do recall some advice I read somewhere to use a cop instead of a mov and specifying a length of 1 (word I think). I think I recall that the person was trying to mov some data from one type to another but having a problem because they wanted the exact binary moved. And the mov was converting when the programmer didn't want that.

But I'm not exactly sure what the problem was since I read it awhile ago. I definitely will try it out though. Being a newbie though I don't have much experience using the cop. Although from what I understand an integer is a 16 bit word and a float is 2 words long... 32 bits.

I do have to admit that I think it's just a bug. But not in the processor firmware but in rslogix itself. My old 1995 dell in work has an ancient version. I did try some testing of the issue though with my non flintstones laptop with rslogix ver 8 and it still has an issue. Again the strangest thing is I can compile it with the older 5/03 processor. Then change it back and it compiles flawlessly. At least that's what I see. The routine appears to run on the newer processor

Thanks again rg. Definitely going to do some test coding this weekend. I haven't been able to try it yet because of working around production but I am wondering if I could put the os301 upgrade rom I have that I used to upgrade my os300 processor. That works fine. 300 doesn't have floats but 301 does. Maybe the upgrade routine checks and will not write an older version over a newer.

Not familiar enough hardware wise but all the 5/03 processors are the L532s. Except in the rslogix processor selection drop down they differentiate them with a letter after the processor name. Probably the firmware. The L532 has os300. But can upgraded to os301. The L532C/D has is 301. The L532E came with os302 original. Then after the same processor came with os302 ver C. The routine actually compiled on the original E with os302. It didn't with os302 ver C.

Same processor. E. Just a different os302 ver C....