Verifying a strings nature?

[RobbyF 0]

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?

Edited 29 Sep 2017 by RobbyF

[kaare_t 155]

You haven't specified the error you get in the PLC, but my guess is an operation error on the DDABIN instruction. First of all, you can make the CPU continue to run even if an operation error occurs. I always select to continue to run unless a customer is very specific (there's no need for the PLC to actually make a stop), the error LED on the CPU will light up red, but it will continue to run. See screenshot of settings. I select "Continue" on all choices.

Second, if you want to actually solve the problem I would first ask the supplier what specifically the scale sends in the string when there is an out-of-scale "value". Then do a compare on the raw format of the string and discard the complete string if it matches the "out-of-scale". This way the DDABIN will never run in case of "out-of-scale".

Do you know if there's a fixed "out-of-scale" string, or can that also change?

Edited 29 Sep 2017 by kaare_t
Forgot picture: Here it is.

[RobbyF 0]

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.

[kaare_t 155]

No problem if there are more than one "out-of-range" return codes, you can just go through several codes and discard message if any match. To continue a bit on this, I always compare the return result binary (compare the hexadecimal representation of the string), before doing any conversion just to avoid the situation you are in right now. If the binaries match a non-string value, then just jump across or disable the conversion function(s). Let us know the progress in your case, nice for others to know in the future.

I agree in programming out errors, and just FYI I always program out errors (not good letting a red 'ERR' light on the CPU when when leaving the customer  ). However I have found that during both development and startup/FAT it's a relatively big job to reset the CPU every time there's a small or large bug... Most often, customers also accept the "Continue" option since the machine operation should stop "normally" instead of the CPU actually going into STOP. In other words, when needed, I develop code that checks for error registers and gracefully stop the machine/plant instead of the CPU actually halts everything immediately. But if graceful stops are not "needed" then it's easier to just let it shut off.

Let us know if you have any other questions!

[RobbyF 0]

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.

[kaare_t 155]

You need to ask the scale distributor/manufacturer what kind of hex (or binary) value the scale transmits when out-of-range. You can also check this yourself by simply generating the faulty situation with heavy objects on the scale, and then monitor the variables in GW2 using e.g. hex view. That way you can view the raw value that is transmitted to the PLC.

After you've figured out what the scale is transmitting (the raw value - not the "black face") then you can make the routine for masking out these nan values.

In other words, you cannot do a compare with "black face", but you can do a compare on a hex value (or binary) of some sort to mask out errors.