RobbyF

Sorry it took so long to get back, This Item had actually become "unimportant" till recently when a influx of new operators, setting heavy items on the scales accidentally, had revived the issue... Turns out the first char in the "Out of Range" string in either direction, Over weight or Under weight, is "☻"... apparently Mitsubishi finds black face highly offensive, and shuts down the CPU immediately. I tried to do a string comparison, but even IQ works alters that char from "☻" to "?" when I drop it on a rung... I have reached out to the scale distributor, and the scale manufacturer, to find out if this string is able to be altered to remove that char, or disabled... I'll be a bit more vigilant in my updates here on the situation. Thanks for reading, and I'm still open to any suggestions.

Thank you for the reply! It is an operation error, and I am checking with the vendor soon to see what the "out of range" error returns. I believe it is different in either direction, negative scaling or over weight (the scales interface shows a different set of chars based on which direction it is). I figured that would be easiest after making the original post. We have had a number of incidents where "Divide/0" have sent our cpu's into a loop, but with our mes interface, and the way our data base works for tracking/traceability we, as a policy, do not let everything continue. We program out possible errors. I am back at work now, I will update this thread with the results. Maybe help someone else in the future.

Hi all, I am trying to add logic to a program, and need someone with more experience. It is a Q series controller, it interfaces with a scale used to verify part conformity. The scale is RS232 connected, it parses an ascii string with the weight back to the PLC, which then does a conversion to binary using DDABIN. The value is compared to both USL and LSL to approve its quality, pass or fail. The problem is whenever an operator bumps the scale or places other components on it, and exceeds the limits of the scale, the string it sends is not numeric. When this happens the PLC has a fit, and requires power cycling the machine... I want to put a verification in before the conversion, that would allow it to disregard any data from the scale that is not numeric. Is there a way to compare or verify the string as being purely numeric, or should I contact the scale vendor to find out what the "out of range" string is and, do a string comparison?   [ $>=   D1648   "1" ] maybe?