Sign in to follow this  
Followers 0
Wordman

Awt Awa Stuck En Bits

14 posts in this topic

This is on a SLC 5/04. There are calls to various subroutines which send ascii to a printer. Every so often (like months at a time) random EN bits toggle on, and the receipts that are print out are messed up. So I have to go in and find the culprits and toggle them back. Attached is an example of one of the subroutines. Any ideas on whats causing/how to avoid?

Share this post


Link to post
Share on other sites
Don't really know whats causing it. Could be many things. Firing two ascii writes at once might do it, maybe a buffer overflow? Is the Ascii Write or Ascii Append instruction hanging or are both hanging? Just a thought, maybe could do something like this for a reset before you send the string to the printer.

Share this post


Link to post
Share on other sites
You're example is showing that you want these rungs to run constantly? In that case, wouldn't it be better to use the DN bits instead of the EN bits? EDIT: okay, you must be conditional executing these sub-routines. I would still execute the 2nd and 3rd Write after the previous Write was DN. Edited by jstolaruk

Share this post


Link to post
Share on other sites
twcontrols: perhaps it is a buffer issue, I will look into something like that. jstolaruk: yes the subroutines are run conditionally. if i were to wait for the DN of the previous block, wouldn't I have to loop the subroutine and wait several scans before it was done? thanks for the replies. it's just weird to track down a problem when it works 99.98% of the time

Share this post


Link to post
Share on other sites
Here is something to try. Unplug the serial port. Start executing the print code. See if the enable bits hang. This would tell you if there is an intermittent problem with the communications to the printer

Share this post


Link to post
Share on other sites
Yes, and maybe thats what the trouble is. If you only scan this subroutine once, the instructions would set the enable bit and because you don't make additional scans, the bit remains set and never gets a chance to update as completed. As a rule, I don't conditionalize JSR instructions. I would prefer to put the conditions on each of the individual rungs in the subroutine (or a common coil made up from the conditions). Then I know that the status bits will always be updated. Skipping the execution of a rung is not the same as a rung being false; the status bits will remain frozen from the last time the rung is executed if skipped. Edited by jstolaruk

Share this post


Link to post
Share on other sites
Just a note that once took me ages to sort out. The DN bit can be on constantly, i.e. if the transmit buffer is empty or if the receive buffer is full. Use the EM bit instead (not EN) which is the same as the DN bit but will be off for at least one scan.

Share this post


Link to post
Share on other sites
You can't send 3 commands at the same time. DN bit from first should trigger the second DN bit from the second trigget 3rd. Now condition for the first one: Are you printing constanly? I hope not, it will be a lot of paper ;) Just put a condition to the first instruction to start printing Set bit OFF and ON if you need print again

Share this post


Link to post
Share on other sites
Boy, these real erratic problems can be a pain. I know this is a extremely rare occasion and you are probably flustered when it happens and have everyone standing by waiting on you when you are clearing the bits, but could you do a screen capture on your R6:25-27 data files when this happens. Might be a little clue in there

Share this post


Link to post
Share on other sites
well you can send multiple commands obviously (some other subroutines fire off over 10 blocks), since it works most of the time. I do agree that it's not best practice, hence the problems i'm seeing. I didn't write the program, I more or less inherited it, so I"m not taking credit for it's flaws Nevertheless, I've decided I am going to re-write it, I agree with your approach. Thanks for the suggestions guys, I'll let you know if I ever see the problem again after I change it.

Share this post


Link to post
Share on other sites
I think this KB directly addresses your issue: G16400 - Using ASCII Instructions on Enhanced PLC-5's Channel Zero and ControlLogix or FlexLogix Processors in USER Mode

Share this post


Link to post
Share on other sites
This is assuming that the 1st string is a initialization string and the last string is some type of form feed Another thought is to use the ACL instruction to add the other two ascii strings to the 1st string before sending. Then you would have to worry about making sure one is sent before starting the next and this should not have any effect on the printing

Share this post


Link to post
Share on other sites
A simple quick fix (not a solution) may be to run a timer from the EN bit, if it is on too long then unlatch it.

Share this post


Link to post
Share on other sites
Actually as I look closer at your screen capture, the first command is a start print and the third command is a blank line. It looks like you would loose a total of 3 characters in the length of your string that you could send. As long as this won't hurt you combine them before you send them to the serial port to eliminate the timing issues completely

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
Sign in to follow this  
Followers 0