SoCold

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

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.

That is great! Thanks.

I am working on a project that has a somewhat involved communication routine to read multiple values from an instrument. This requires that I have several long messages in message composer that I am using to both request the data and also to parse the response. I will need to use this technique in several different projects. Is there any way to export the messages from the message composer and then import them into a new project? It takes several hours to manually rebuild these messages in each new project.

I have an instrument (pressure gauge controller) that uses an FTDI chip as an integrated USB-Serial converter. Are there any plans (Or work-arounds) to support chipsets other than Prolific?

I think I read somewhere that only USB-Serial adapters that used the Prolific drivers would work. It would benefit me if some other common drivers were also ported into the Unistream.

It would be nice to have the ability to talk to PROFIBUS-DP.

I've got it working. Thanks for your help.

Thanks for the response. Will passing the result value from Linearize to the tag assigned to my AO cause it to output my desired voltage? This is my first experience with Unilogic and PLCs, so if there are any other tips for working with analog outputs I'd appreciate hearing them.

Is there a sample of how to use analog out? I have a Unistream 10" with a UIS-WCB1. I need to control an output between 0V and 5V. Thanks.