scarince
Lifetime Supporting Member
In a 1769-L16ER-BB1B, ver24:
I'm probably trying to do something impossible with FSC, but I can't explain this behavior:
I have a string array [500] elements long and I sort part numbers with a normal bubble sort. It takes a long time of course.
I had an idea that maybe instead of iterating through and doing one operation per scan, that maybe I could use the FSC instruction to do the comparison of the data in the two array positions.
In the attached logic I use FSC with an expression that says "MyArray[control_2.POS] > MyArray[control_2.POS + 1]". That's not that actual syntax...I'm simplifying.
If it finds that the two values need to be swapped then I copy each value out and copy them back in with the array positions swapped. Then I clear the .IN bit.
So, it works. The code attached will work.....but it will only work if I put in debugging bits and then manually execute one rung at a time. What I mean by that is that if I let the FSC run until it finds two values to be swapped, it will run and stop correctly at a point in the array where the string in position X is larger than the string X+1. Once the FSC stops (.FD is set) then I manually trigger rung 8 and the COP instructions execute correctly. Finally, I manually trigger run 9 and I clear the .IN bit to allow the FSC to run.
If this code runs "normally" (as displayed in the attachments) then what happens is that when I enter a new part number into the first null position of the array then the COP instruction in rung 8 will garble the data. For example, if the number to be moved in the array is "999555" then when it copies it to the temp storage tag, it becomes "999$00$00$00$00" or something like that. There are other strange things related to where in the array the data gets copied back to, as if the .POS value was still changing even though .IN is set. I can confirm POS is not moving when I do this manually.
I even tried delaying the clearing of the .IN bit to see if copy needed more that one scan to complete. I delayed it 10 scans but the results were the same.
I'm not asking how I can sort this better, or even how to get this to work. What I'm really asking is if one of you experts can explain how the function of FSC is related to the normal scan, and if there is any explanation for why (at least in this context) logic would work when executed one step at a time but not when allowed to run at the normal scan rate.
If nobody can or wants to answer this, then can someone just explain how in FSC the .POS value is incremented and how that value is changed relative to the normal logic scan.
The two attached files are the same. The .zip is the .L5X file.
Thx.
I'm probably trying to do something impossible with FSC, but I can't explain this behavior:
I have a string array [500] elements long and I sort part numbers with a normal bubble sort. It takes a long time of course.
I had an idea that maybe instead of iterating through and doing one operation per scan, that maybe I could use the FSC instruction to do the comparison of the data in the two array positions.
In the attached logic I use FSC with an expression that says "MyArray[control_2.POS] > MyArray[control_2.POS + 1]". That's not that actual syntax...I'm simplifying.
If it finds that the two values need to be swapped then I copy each value out and copy them back in with the array positions swapped. Then I clear the .IN bit.
So, it works. The code attached will work.....but it will only work if I put in debugging bits and then manually execute one rung at a time. What I mean by that is that if I let the FSC run until it finds two values to be swapped, it will run and stop correctly at a point in the array where the string in position X is larger than the string X+1. Once the FSC stops (.FD is set) then I manually trigger rung 8 and the COP instructions execute correctly. Finally, I manually trigger run 9 and I clear the .IN bit to allow the FSC to run.
If this code runs "normally" (as displayed in the attachments) then what happens is that when I enter a new part number into the first null position of the array then the COP instruction in rung 8 will garble the data. For example, if the number to be moved in the array is "999555" then when it copies it to the temp storage tag, it becomes "999$00$00$00$00" or something like that. There are other strange things related to where in the array the data gets copied back to, as if the .POS value was still changing even though .IN is set. I can confirm POS is not moving when I do this manually.
I even tried delaying the clearing of the .IN bit to see if copy needed more that one scan to complete. I delayed it 10 scans but the results were the same.
I'm not asking how I can sort this better, or even how to get this to work. What I'm really asking is if one of you experts can explain how the function of FSC is related to the normal scan, and if there is any explanation for why (at least in this context) logic would work when executed one step at a time but not when allowed to run at the normal scan rate.
If nobody can or wants to answer this, then can someone just explain how in FSC the .POS value is incremented and how that value is changed relative to the normal logic scan.
The two attached files are the same. The .zip is the .L5X file.
Thx.
