Posted 7 Sep 2018 (edited) 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: 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 7 Sep 2018 by JLN Share this post Link to post Share on other sites
Posted 7 Sep 2018 are you sure that instruction is called? i see no green rung before it... Share this post Link to post Share on other sites
Posted 7 Sep 2018 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
Posted 7 Sep 2018 how is the UDT declared? why is the LEN so large value? Share this post Link to post Share on other sites
Posted 7 Sep 2018 Don't know why the LEN is so large, but below is the declaration: Share this post Link to post Share on other sites
Posted 7 Sep 2018 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
Posted 7 Sep 2018 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
Posted 7 Sep 2018 (edited) 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 7 Sep 2018 by b_carlton 1 person likes this Share this post Link to post Share on other sites
Posted 7 Sep 2018 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
Posted 8 Sep 2018 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
Posted 8 Sep 2018 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
Posted 9 Sep 2018 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
Posted 10 Sep 2018 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
Posted 10 Sep 2018 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
Posted 10 Sep 2018 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
Posted 10 Sep 2018 (edited) 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? Edited 10 Sep 2018 by JLN Share this post Link to post Share on other sites
Posted 10 Sep 2018 (edited) 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 10 Sep 2018 by b_carlton Share this post Link to post Share on other sites
Posted 10 Sep 2018 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: 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
Posted 10 Sep 2018 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
Posted 11 Sep 2018 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
Posted 11 Sep 2018 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
Posted 11 Sep 2018 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... Share this post Link to post Share on other sites