Jump to content

Inconsistent Results with RS232 Com


SoCold

Recommended Posts

I have a Unistream project that uses a UAC-02RS2 communications module. The 2 RS232 ports are connected to 2 different pressure gauges from which the pressures are read on a regular interval. Occasionally I have a problem where the communication locks up and I get no updates. I have found that when this happens the "UAC-02RS2-COM-232_0.Send Status" tag is set to a value of "1". When I set this value back to 0 the communication restarts. (Note that this value is an Int16) I believe that the communication problem is caused by the pressure gauge, not the PLC, but I am trying to work around it by implementing a watch-dog timer in the PLC that will set the "Send Status" value to 0 if it has been at 1 for too long. 

 

The problem that I am seeing is that using identical ladder rungs with the only difference being the counters and the specific RS232 port, the watchdog works for com2 but not for com1. What is happening is that the first "Not Equal" block in rung 10 is ignored and the counter increments even when the "Send Status" value is the same as the set value of "0".  On Rung 13 everything behaves as I'd expect. I cannot figure out how to keep RSCOM1Counter from incrementing. Even when Unilogic is online with the PLC, the "not Equal" block does not show that it is active (it is not red) but everything behaves as if it is. I have tested this and it is only happening for COM1.  Is there some difference between COM1 and COM2 that could account for this behavior?

If there is a better way to reset  communication I'm open to other ideas, but for now I'm stumped as to why essentially identical rungs are not behaving the same, especially the "Not Equal" block being ignored. 

 

image.thumb.png.b27d98c32ef70ae7e07a553230938a93.png

Link to comment
Share on other sites

  • MVP 2023

Hi SoCo, I don't use Unilogic at all, just a Vision man.......ooops.....person (with external gonads!) 

But....on the actual reads from the sensors, are you doing your reads concurrently?  What happens if you split the reads equidistant in timing?  What is the actual "regular interval" time on the reads anyway?

Along the same lines, what happens if you flip-flop between 10 & 13 at a given time interval so that they are both not doing it all the time..   ie only enable rung 10 this second, only enable rung 13 the other one,  perhaps with a small time buffer between each alternate.  Behaviour exhibited after doing this would perhaps help in analysis. 

cheers, Aus

Link to comment
Share on other sites

Hi Aus, 

Thanks for your advice about splitting the reads in equidistant timing. Several years ago when I first built this project I was smart enough to do that. Com1 reads each second on positive transition and Com2 each second on negative transition. I've evidently lost some mental capacity because I was checking send status on both ports on positive transition. That being the exact time (or at least very close to it) that Com1 was communicating, the send status was never going to be zero. Changing the Com1 watchdog check to be on the negative transition fixed my problem. 

Thanks again! 

SoCold

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...