JLN

ASCII Question

22 posts in this topic

STOR.PNG.a83c1696ae6ea085992e8c7cd3c46e6

I am attempting to convert a string to a real.  The command is simple:  STOR.  However it's not working.  I am converting a user-defined tag of 5 characters of ASCII to a real variable.  The value in the ASCII string is '33.07'.  But the command shows 10 characters of '33.07$1DP2' (please see images attached).  I don't understand why the UDT has defined 5 characters, yet 10 are being stored.  The STOR command does not work; and I am suspicious that the extra characters are interfering with the functioning of the command:

STOR2.PNG.c34bcf9316c4434628f7157019a48f

As you can see above, the command is not yielding the correct result which would be 33.07.  Now, the online help say the command ignores any characters following the numeric value, and should yield the real value.  Which it is not.

Any ideas?

 

 

Edited by JLN

Share this post


Link to post
Share on other sites

are you sure that instruction is called? i see no green rung before it...

Share this post


Link to post
Share on other sites
1 minute ago, panic mode said:

are you sure that instruction is called? i see no green rung before it...

Yes it is.  Its just the clipped screenshot that doesn't show the power rung.   But thanks for the suggestion.

Share this post


Link to post
Share on other sites

how is the UDT declared? why is the LEN so large value?

Share this post


Link to post
Share on other sites

Don't know why the LEN is so large, but below is the declaration:

STOR3.PNG.2ef0fcb6bd1ea2052d5caae3917613

Share this post


Link to post
Share on other sites

Where does the data come from? Is there a reason to use a UDT instead of the predefined STRING data type?

Share this post


Link to post
Share on other sites
9 minutes ago, Joe E. said:

Where does the data come from? Is there a reason to use a UDT instead of the predefined STRING data type?

The raw data comes from a hand scanner; and is then parsed into the BCN_Q variable.  I created the UDT to keep the string at 5 characters max.  So it's correct in the SINT array; but not in the internal value (which is weird).  

Share this post


Link to post
Share on other sites

If  you force 5 into the .LEN does it convert properly? I believe whatever is storing the string is messing up the length. Is 33.07 an expected value? Could it possibly be something like 2833.07? (Interpreting the messed up length code as data. But first 2 would be 'Q' then x1D (possibly string lead in characters?)

 

Verify the structure of the transmitted string. Is the parsing meant to break out a length value?

Edited by b_carlton
1 person likes this

Share this post


Link to post
Share on other sites

The corrupted LEN value is very suspicious, though it shouldn't cause the STOR instruction to not work.

Look at the logic that moves data into that String, and figure out why the Length is not 5.   I've got a feeling you have something over-writing the BCN_Q tag.

1360867896 (decimal ) is  51 1D 32 38  (hex), which is Q [GS] 2 8  in ASCII (0x1D is a Group Separator control code).     The presence of the letter Q and the separator byte 0x1D in the tag name, in the "extra" data, and in the corrupted Length is suspicious.

I've got a feeling you will find logic that uses a COP to put data into the base BCN_Q tag (which will start with the 4 byte Length element) instead of starting in string data section (BCN_Q.Data[0] ).

 

 

1 person likes this

Share this post


Link to post
Share on other sites
2 hours ago, b_carlton said:

If  you force 5 into the .LEN does it convert properly? I believe whatever is storing the string is messing up the length. Is 33.07 an expected value? Could it possibly be something like 2833.07? (Interpreting the messed up length code as data. But first 2 would be 'Q' then x1D (possibly string lead in characters?)

 

Verify the structure of the transmitted string. Is the parsing meant to break out a length value?

I am now away from my machine; and I haven't force anything into LEN yet.  I will give it a try when I return.  Yes, 33.07 is the expected value.  Yes parsing will break out a length value; but that LEN value is just plain weird.

Share this post


Link to post
Share on other sites
1 hour ago, Ken Roach said:

The corrupted LEN value is very suspicious, though it shouldn't cause the STOR instruction to not work.

Look at the logic that moves data into that String, and figure out why the Length is not 5.   I've got a feeling you have something over-writing the BCN_Q tag.

1360867896 (decimal ) is  51 1D 32 38  (hex), which is Q [GS] 2 8  in ASCII (0x1D is a Group Separator control code).     The presence of the letter Q and the separator byte 0x1D in the tag name, in the "extra" data, and in the corrupted Length is suspicious.

I've got a feeling you will find logic that uses a COP to put data into the base BCN_Q tag (which will start with the 4 byte Length element) instead of starting in string data section (BCN_Q.Data[0] ).

I quite agree Ken.  I will send a screenshot of that COP command when I return to work. 

BTW Ken, you and I used to discuss these sort of things on the telephone back in the late 1990's and early 2000's.  Hope you remember me.  This is Jeff Nims.

Nice to hear from you again!

 

 

Share this post


Link to post
Share on other sites

break problem into smaller ones and test each separately.

for example, test STOR with own data first, not with string received from scanner. this will give you opportunity to see how instruction works (always get familiar with each and every instruction before using it in real program). 

5 characters is ridiculously short to receive a string from scanner. there will always be misread scans etc. five characters is probably just enough for overhead and padding. you can trim it down later but i would say go for 30+ characters while developing.

check your code... you only show one instruction but is this really a sample or changing data, index is clearly invalid. lookup GIGO principle

 

 

 

 

Share this post


Link to post
Share on other sites
On 9/7/2018 at 3:39 PM, b_carlton said:

If  you force 5 into the .LEN does it convert properly? I believe whatever is storing the string is messing up the length. Is 33.07 an expected value? Could it possibly be something like 2833.07? (Interpreting the messed up length code as data. But first 2 would be 'Q' then x1D (possibly string lead in characters?)

 

Verify the structure of the transmitted string. Is the parsing meant to break out a length value?

Well, creating another STOR command and using a string test word with '33.07' in it, the command worked.  I tried forcing a number into LEN, but the system just writes that long value right back in.  It appears the command is not following the rules that online help says it should.

Share this post


Link to post
Share on other sites
23 hours ago, panic mode said:

break problem into smaller ones and test each separately.

for example, test STOR with own data first, not with string received from scanner. this will give you opportunity to see how instruction works (always get familiar with each and every instruction before using it in real program). 

5 characters is ridiculously short to receive a string from scanner. there will always be misread scans etc. five characters is probably just enough for overhead and padding. you can trim it down later but i would say go for 30+ characters while developing.

check your code... you only show one instruction but is this really a sample or changing data, index is clearly invalid. lookup GIGO principle

 

 

 

 

No.  The hand scanner is reading 65 characters in from a 2D QR code.  This includes information like part number, lot number, weight, etc.  This all comes in as ASCII, and most just remain ASCII to be passed to plant database.  I need to convert the weight value to a real to do some math with it.  That's the only reason for this.

Share this post


Link to post
Share on other sites

Having verified that the STOR works correctly on a correct string the attention should shift to the method of parsing the data. Can you give more information on that?

Share this post


Link to post
Share on other sites
31 minutes ago, b_carlton said:

Having verified that the STOR works correctly on a correct string the attention should shift to the method of parsing the data. Can you give more information on that?

OK.  Below is the whole rung that carries out the transfer from the scanner to the string Barcode_Scan_BCN_1 for the length of the scan.  Then copying the information to different strings using COP and the length of the data needed.  These are the UDT,s declared for the size needed.

As far as I can see, this is correct; but the weird and huge LEN values after copying data make me certain there's a better way!

Ideas?

 

STOR4.PNG

Edited by JLN

Share this post


Link to post
Share on other sites

Modify the copy for BCN_Q as follows:

COP   Barcode_Scan_BCN_1.DATA[22]   BCN_Q.DATA[0]   5   (this should copy the 5 characters)

and add the following instruction

MOV  5  BCN_Q.LEN  (this should set the length properly.)

Note - this is pretty much the same as the first two output instructions on the rung which copy the characters then transfers the length.

 

If satisfied with this you may need to modify the other COPY commands as appropriate.

If there are continuing problems can you provide a link to the contents of the 65 character string returned from the scanner?

Edited by b_carlton

Share this post


Link to post
Share on other sites

Carlton:  That did it!  I had to remove the offset of 4 words by starting at [26] instead of [22]; but once I did that and followed your suggestion:

STOR5.PNG.d8ca3e841f98cedd1c11b0f66fb188

 

BTW:  I just moved form Yakima to Richland 2 months ago.  I'm surprised we haven't met one way or another.

Regards,

Jeff

Share this post


Link to post
Share on other sites

I'm glad to have helped.

I'm retired from MARQ Packaging in Yakima. I only worked on one QR scanner application using an AutomationDirect DL260 system. The needed information was buried in the returned string at a variable offset because of tab delimited fields. I had to use multiple searches to find the 4th and 5th tabs then string extraction to get the characters between them. Not only that but the customer decided to use different data formats within that extracted string. What fun. I would have loved to get data at an easily predictable point.

Share this post


Link to post
Share on other sites
5 hours ago, b_carlton said:

I'm glad to have helped.

I'm retired from MARQ Packaging in Yakima. I only worked on one QR scanner application using an AutomationDirect DL260 system. The needed information was buried in the returned string at a variable offset because of tab delimited fields. I had to use multiple searches to find the 4th and 5th tabs then string extraction to get the characters between them. Not only that but the customer decided to use different data formats within that extracted string. What fun. I would have loved to get data at an easily predictable point.

Lord in heaven.  That’s what I’m up against right now.  The client just, and I mean just changed their minds.  Well anyway, thanks again.  I’m familiar with MARQ.  I lived on the west side (60th ave).

Be well.

Jeff 

Share this post


Link to post
Share on other sites

Getting information from a customer can be like pulling teeth. For the longest time in the QR development that's all we knew, there would be a QR code, nothing about what was in it or where it would be placed on the product. Our contact at the customer's was about 3 or 4 steps away from those who were making the decisions and it took several days to answer each of our questions. It was at about a week before the machine was finished and ready for testing before we got some answers. I was working out the decoding logic on our shop floor as they were trying to test run the machine.

Share this post


Link to post
Share on other sites

Man.  That's the worst.  Well, almost as bad as having the customer appear at the shop for a buy-off just after they made more changes.  The machine has to run; and you're banging out code to fit their last changes...  :burn:

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now