Skip to Content

Register Login

Default Header

(header konnte nicht geladen werden)

Navigation

SRD instruction with 32 bit shift

Created by: Tauseef at: 7/30/2009 10:41 PM (13 Replies)

Rating (2)

Thanks 2

Result pages:: |; 1 | 2; |

14 Entries

Entries per page: 10 | all

8/5/2009 9:37 AM	Rate (0)
Sydney Gold Member Joined: 1/4/2008 Last visit: 12/22/2025 Posts: 703 Rating: (98)	Hello Fritz, don't need to apologize, I'm only the human so I could make a mistakes But in this case you probably didn't get the meaning of my suggestion, maybe I wrongly wrote the post. It was just pssibility where could be this problem, BUT ANYWAY there has to be the jump instruction for the correct logic! It isn't about unnecessarily instructions, these instructions can't be performed because there is a logic switch above which says which comparation should be performed, when there should be the first one and the bit isn't set, the JP instruction isn't performed and the code continues so there has to be the JU instruction across the second comparation. Otherwise in the second comparation the counter variable is crashed by the subtraction and the loop is broken, the function won't work correctly. Also the higher loop won't work in this code, because of the subtraction - it compares only once the higher doubleword and then after subtraction switches to the lower one. I suggest to use the two independent loop or one relative, but this code (in FC503) won't work properly. So as a result, my suggestion was rather for correction of the code itself with possibility of cause the mentioned fault, that's why I suggest to look where exactly the code finishes, because we don't have the whole code, just the function and the problem could be somewhere else. Concerning the mentioned fault, when there's unfinished cycle as first I look on the loop logic because it is mainly the problem, not the firmware (of course the firmware could cause it also). So he has to find where the unfinished loop is and then find the reason, if it would be the bad performing of some instruction, it could be tested independently, here just with simple code: L 32 L DW#16#80000000 SRD A >0 S Mx.x hope this code is clear... Regards Sydney

Suggestion To thank Quote Answer

8/5/2009 11:49 AM	Rate (0)
fritz Diamond Expert Joined: 10/7/2005 Last visit: 1/14/2026 Posts: 3054 Rating: (1062)	Sydney Hello Fritz, don't need to apologize, I'm only the human so I could make a mistakes No worries Sydney, I have been know to err too, but in this case stick with what I wrote earlier.
	Cheers fritz The advice and opinion given in this thread is that of the author and does not necessarily reflect the views of I S Systems Pty Limited. To find out how I S Systems can help you with your automation needs please visit www.issystems.com.au.
Suggestion To thank Quote Answer

8/5/2009 3:10 PM	Rate (1)
Tauseef Posts: 7 Rating: (1)	Sydney Also the higher loop won't work in this code, because of the subtraction - it compares only once the higher doubleword and then after subtraction switches to the lower one. I suggest to use the two independent loop or one relative, but this code (in FC503) won't work properly. First of all, thanks for all the attention and time to this post, Sydney and Fritz. Regarding the comment as above, actually the subtraction operation does not modify the value of the "output int", which is thevariablethat is mapping the faults in the HMI and the one which we are looking at to decide which word to shift (the higher or the lower one). The subtraction operation only determines the number of shifts for the higher word for the LL messages. As such after subtraction we do not switch back to the lower word, as our search continues from the existing value of output int (if for example output message bit 33 is high and we enter the second word, then output int will take on the value of 33 and we exit FC503 -then next time we enter FC503and the loop will be executed we will increament one, so for the next loop we will look at the 34th bit, then the 35th bit, until we find another bit high in the second word - For value greater than 64 we would reset to 1, and then start searching a high bit in the lower word again until we find another bit high - as soon as we find a high bit, the loop is broken and we exit FC503 - we do have a condition at the top - the first line in the code where we prevent entering this loop if both words are zero, i.e no high bit to avoid executing this loop on an infinite basis). The code is in service and works fine and displays and scrolls all messages with the exception of message 32 and message 64, which we do not use deliberately because of the issue with the CPU. Thank you for the tip for monitoring the breakpoint in the program using the stacks tabunder module information. Next time we have access to the CPUand can test the code with and without the firmware upgrade, i will make a note of it, and maybe that can help us with resolution of the issue. I am very optimistic about Fritz' assertion though, and am hoping the firmware update will do the trick.
Tauseef Posts: 7 Rating: (1)	Last edited by: Tauseef at: 8/5/2009 3:15 PM
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users fritz

8/5/2009 7:46 PM	Rate (0)
Sydney Gold Member Joined: 1/4/2008 Last visit: 12/22/2025 Posts: 703 Rating: (98)	oops, sorry guys, Fritz were right, this is my mistake... Have downloaded the code yesterday night, made a quick look and deleted the project, and my posts were about I thought it was there. I downloaded the code again now and see that there's just increment saved, not the subtraction. Next time I would rather think twice before writing probably need to have a break. Or as we say in our country, measure twice before cutting... I'm glad that at least something little from my post were maybe usefull. Regards Sydney

Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users fritz

|

Share this page:

Share this page on...

Follow us on