Unilogic ASCII string to REAL conversion

[hotwires]

I have an Ohaus scale with a serial printer port connected to a Unistream 5" pro. A part is place on scale and a comparison is made to a valid weight range. I finally have a working model for getting weight ASCII string into a REAL but it's very clunky. There has to be a better way. The biggest issue with my conversion rung (before using mul & add FB's) is if I weight in a part at 10.39 grams and the REAL displays as such and the next weight is 7.43 grams (THE TENS PLACE IS A NULL ((BLANK)) CHARACTER) the real displays as 0.43 grams. The tenths and hundredths always read out okay because the zeros present regardless of fractional weight. Is there a cleaner way to take "   10.39 g" ASCII,  narrow to "10.39" ASCII and convert to REAL D#10.39?

Next issue, I want the buzzer (more of a beeper) to sound for a short burst when a valid weight is received. In Vision there was a simple SB bit that would sound buzzer for any duration the OTE was true. I have tried several constructs with the BUZZER START AND BUZZER STOP actions but always end up with a continuous buzzer or a chatter. Please and thank you for any assistance. 

 

Please see "WEIGH IN" subroutine for example of the code I have that works but could stand to be simpler.

JorachoPressNewScale12-20-18e.ulpr

[Ausman]

Hi Hots, long time no hear.

On the buzzer, your issue might be related to as discussed in this post.  I don't know whether the delay issue is fixed or not:

On the rest of your question, it is for someone else!

cheers, Aus

[Joe Tauser]

Have you considered doing this with a virtual decimal place and working only in integers?  If the scale always returns 0.xx precision you should be able to extract the number with one operation.

Joe T.

[hotwires]

Joe:

 

Please elaborate. Scale returns x.xx, xx.xx precision. By virtual decimal place you mean "10.41=1041"? This is what I did on AB 5/05 proof of concept program. I have to strip the ASCII decimal character and join the tens/ones  characters with tenths/hundredths characters (concatenation?). I had the notion maybe the message parser could pull what I wanted out of the ASCII's rear end.

It's weird that the STRING to NUMBER block won't convert double number ASCII bytes that don't include a digit (null) in the tens place. RSLogix didn't care about the tens place, would convert D#10, D#7, D# .41, etc. Parsing out tens and ones individually got me around the road block. Maybe I'm missing something there?  The INT to REAL command actually works with simplicity (something not as simple in RSLogix). The null ASCII tens place caught me by surprise a bit (actually a byte to be exact). I am hoping to ditch the MULTIPLY and ADD FB's.

[hotwires]

Where can I find detailed help or an example of the "Remove from String" function?

[Joe Tauser]

12 minutes ago, hotwires said:

By virtual decimal place you mean "10.41=1041"

Yes  This is what I had to do with a scale interface I just did in Visilogic but it removed the decimal automatically provided it always comes in the same place.  I looked for the existence of the "g" character and the converted the characters in front of it-

The integer weight landed in ML 70.  I'll have to load a UniStream up and see how that ASCII-Num block works.

I generally don't use real numbers in the PLC unless absolutely needed  for advanced calculations. 

Joe T.

 

[hotwires]

On December 20, 2018 at 10:37 PM, Joe Tauser said:

Yes  This is what I had to do with a scale interface I just did in Visilogic but it removed the decimal automatically provided it always comes in the same place.  I looked for the existence of the "g" character and the converted the characters in front of it-

The integer weight landed in ML 70.  I'll have to load a UniStream up and see how that ASCII-Num block works.

I generally don't use real numbers in the PLC unless absolutely needed  for advanced calculations. 

Joe T.

 

Thanks Joe, that is some meat and potatoes. Maybe I can equivicate in UniL and get same result with less FB’s than I am currently using. Trying to get out of the over kill programming habits, sure it works but less is more in ladder. Make it simple for the next Guy.

UPDATE: Now I'm curious how Visilogic handles to the ASCII TO NUM conversion. @Joe TauserWere your ASCII strings padded with leading zeros left of the decimal? I.e.: 0123.45, 0010.41, 0007.26 in units of weight?

[hotwires]

Sounding buzzer logic solved after a phone call with tech support. The “start buzzer” and “stop buzzer” when triggered by a bit/coil MUST have set coils “-(S)-“ for OS to trigger and NO associated RESET coil is needed (they self reset). This was counterintuitive to me, but when applied it works.

[hotwires]

I'm managed to figure out UniLogics: "string to num", "replace", and "find in substring" on my own through trial and error. "String to num" will not interpret spaces (20h) in place of leading zeros in an ASCII string that you want converted to an integer. This presented me a dilemma since my device would send: ASCII "123.45 g", " 23.45 g", "   3.45 g", or "   0.45 g".  The only assured zero place is the ONES digit. Using an iteration of "find in string" I got a count on the number of spaces left of the decimal point, used that to drive "times to remove" in "remove from string" only then could I rely on "string to number" to function regardless of tens and hundreds places being blank (spaces).

[hotwires]

UPDATE:

FOR REFERENCE....

I took the time to see how a Vision V430 handles ACSII to INTEGER conversions:

Visilogic will convert ASCII strings with:

-leading zeros

-leading spaces

-trailing spaces

-trailing letters

It will not accept:

-leading non numeric characters

 

Unilogic will only convert strings with:

-leading zeros

*Leading and trailing non numeric characters must be removed before conversion.