Unistream - Problem with Modbus RTU Connection

[Joa]

Hi, I'm having trouble with a Modbus RTU connection and unfortunately I don't have enough experience to understand the problem. In my project I would like to control 2 or more control valves that can be operated digitally and analogue. Communication with the first valve takes place via a USC-X10-RA28 expansion module (2-wire serial Modbus RTU interface), all other valves are connected with a daisy chain cable. When sending setpoints/operating modes I sometimes have to click the button twice and after a while the connection may hang (status 1). I noticed that the Com Rx buffer is running full to the value 4096 and then the Rx drop counter starts counting. I assume that the PLC can no longer buffer the received bytes and so the data is lost. Am I right and how could this problem be solved?

Thank's & BR

Joachim

 

[Ausman]

Depending on the speeds you are using and length, do you have all termination resistors in the chain set correctly?  If none onboard the valves etc, you need to fit one to the last one in the chain.  This would be the first thing to try.  Some people say that termination can supposedly be ignored on lower speeds and lesser distances.  I always fit it regardless.  Also, are you using proper shielded cable earthed correctly?

I'll repeat an often quoted thing to do;  trial all your connections on your PC first.  Once you've learnt all that and got it working ok, THEN shift the info you've found that works ok to the PLC.  It is so much easier to discover eveything using the PC.

cheers, Aus

[Joa]

Hi Ausman, thank's a lot for taking time. I checked again, The dip switch of the last valve for the terminating resistor is set. What I do next is asking the supplier why signal cable is not drilled and shielded. It was included in the package..I would also like to measure the signal quality...

Cheers

Joachim

[Joa]

Hi again, 

Meanwhile I checked the signals & voltage levels of the modbus connection and I have some doubts about it. It would be great to get your opinion....

The voltage level of the 2 wires in idle(No commands sent) are:

U (/D) =1,75V    

D (D) =1,45V

U (/D-D) =0,3V

 

Spec. of 2 wired serial modbus describes:

U (/D) = 2,8 V

U (D) = 1,9 V

U (/D-D) =0,9V

 

..also checked data transfer signal with oszi. 

 

Could this be the reason for my com problems? ..probably yes I guess

 

 

[Joe Tauser]

Those voltages do look low. 

RS485 doesn't always work when you wire it the way you're "supposed" to. I've found the 120 ohm terminating resistors can pull the signal down. 

Try experimenting with removing the terminator at one end or the other. Or both. 

 

Joe T. 

[kratmel]

After reading the first post of your topic, I  come to the conclusion that the main problem in your system is the wrong network management strategy.

The Modbus network assumes the presence of one PLC master and many slaves. Unfortunately, I do not have information about your slave devices and therefore cannot say how they react to your requests. That is, if a message was sent, the device to which it was addressed must do something. It usually sends the response provided in the documentation.

Until a response is received, the PLC should not send anything. If at the moment of the slave's response the master tries to send something - a collision occurs - in fact, this is a short circuit of the network.

I see horizontal lines on your signal - it shouldn't be there. There must be either high or low levels in the network (diferential signal present on foto). Horizontal dashes (lines in low-high transition) are the fact of a short circuit in the network when one transmitter transmits 1 to the network and the other at the same time 0.

The signal will accordingly have an average value, i.e. (diferential  0V).

My recommendation is to make a work algorithm for only one valve. Programmatically ensure such a mode of operation that there is no subsequent signal transmission until a response is received from the slave (logic or timing). Next, extend the algorithm to other valves.

I don't have much experience with Modbus programming in Unistream, but I think that your problem is actually in the master-slave communication strategy.

[Joa]

Thank's a lot for your feedback. 

Joe, I guess the same. ..and I already made some measurements (see sketch) with termination dip "on" and "off" -It doesn't make any difference concerning Voltage levels. This is something I don't really understand. Next idea is to implement a termination box etc. with adjustable potential for the signals...(Honeywell RS-485-PCD7.T162)

 

Kratmel, I had the same idea a couple of weeks ago so I wrote a program where com commands were processed sequently with a time delay of 500 ms in aperiodic manner just like the way shown at

UniLogic_Examples\UniLogic Examples_V1.32 Rev 61\Communications\MODBUS RS485

I still have theses Rx drops after Com RX buffer is full. So it must be something else

Oszi shows following...

I'm not a modbus specialist...what do you think. Is it correct if TX signal looks different to RX?

 

I'm looking forward to more inputs

 

 

[kratmel]

1 hour ago, Joa said:

Is it correct if TX signal looks different to RX?

Maybe no.

Please post slave modbus unit pdf or model #.

Is it possible that you have two unit online with the same ID?

 

P.S. Please try to start Modbus via PC....

On 9/15/2024 at 3:22 AM, Ausman said:

trial all your connections on your PC first.  Once you've learnt all that and got it working ok, THEN shift the info you've found that works ok to the PLC.  It is so much easier to discover eveything using the PC.

 

[Joa]

The 2 connected slaves different ID's

attached the pdf of the slave valve..

 

 

I also tried some tests with modscan...-some responses have checksum error 

 

Novocon_data_sheet.pdf

[Joa]

..further I have noticed that if 2 slaves are connected the Rx Signal looks not correct at the end of the chain compared to the signals with one slave ..however data drops occur in both cases.

2 slaves

 

1 slave

 

[Ausman]

I don't use Unistream, but it strikes me as odd that your slave IDs are 1 & 2.  What is the PLC's network ID?  I don't know but I'm guessing it would default to 1?  Perhaps increase your slave IDs to say, 4 & 5, and see what happens.

I actually don't use ID 1 in a modbus network, only higher, as many devices default to 1.  This lets a new/replacement device be added to the network and the PLC can manually adjust the ID if programming is set up to allow it.  This is only useful if the the device works as wanted out of the box, but if it needs tweaking then it is first done on the PC and the appropriate ID done at the same time.

[Joe Tauser]

What baud rate are you running?

According to the Novocon data, the device auto-detects the baud rate.  I'd try your tests at 9600 8N1.

Joe T.

[Joa]

3 hours ago, Joe Tauser said:

What baud rate are you running?

According to the Novocon data, the device auto-detects the baud rate.  I'd try your tests at 9600 8N1.

Joe T.

Hi Joe, now I tried with 9600 8N1 with only 1 valve, before it was running with 19200 with 2 valves... no positive effect:(, I still have drops after Com Rx buffer run full. I'm wondering if this might be the reason. ...buffer too small or missing reset??? What do you think, is this possible?

P.S. I think Auto baud detection works only with Bacnet on this system.

Thank's a lot for your support.

 

 

 

[Joa]

6 hours ago, Ausman said:

I don't use Unistream, but it strikes me as odd that your slave IDs are 1 & 2.  What is the PLC's network ID?  I don't know but I'm guessing it would default to 1?  Perhaps increase your slave IDs to say, 4 & 5, and see what happens.

I actually don't use ID 1 in a modbus network, only higher, as many devices default to 1.  This lets a new/replacement device be added to the network and the PLC can manually adjust the ID if programming is set up to allow it.  This is only useful if the the device works as wanted out of the box, but if it needs tweaking then it is first done on the PC and the appropriate ID done at the same time.

Hi Ausman, I changed the slaves IDs to 4 & 5 as you proposed. Unfortunately without any progress..I still have drops after full buffer

this is a tough one and slowly I'm running out of ideas

 

Thank's a lot for your time

 

[kratmel]

I think that you must set  parameters  to "fixed" (not default- marked by red position). If it is not fixed for all valve - maybe Unistream try to send TX and valve try to found correct Baud rate and parity.  At this moment wrong RX is go to buffer where Unisream do not recognise correct checksum. These are my guesses - but this hypothesis must be tested.

 

[Ausman]

All the above new answers are likely right.  Now knowing the device helps...!

I know this might seem a dumb question, but how many registers are you trying to read/set in one hit?

Don't forget that 485 is essentially very slow, especially if it ends up needing 9600,  and time allowances have to be made to accomodate buffer clearing b/n further action.  Also check that there is sufficient time allowance for all fault sequences to run through with safety margins.

Also, just out of curiosity, what is Unistreams' default ID?

[Joa]

Hi, I made tests with different versions...

In my project I have up to 25 periodic and 15 aperiodic commands only for one valve. But I made tests with only 3 registers to be read. The problem remains the same...even in the version with only with aperiodic commands I get drops after buffer is full.  However the registers can be read anyway and the Integers can be transformed into Real anytime

It's a good point you mentioned that 485 needs some time for buffer clearing...this is something I don't understand. How can I have influence in the timing to make sure that theres enough time between the commands?

[Joa]

19 hours ago, kratmel said:

I think that you must set  parameters  to "fixed" (not default- marked by red position). If it is not fixed for all valve - maybe Unistream try to send TX and valve try to found correct Baud rate and parity.  At this moment wrong RX is go to buffer where Unisream do not recognise correct checksum. These are my guesses - but this hypothesis must be tested.

 

Hi kratmel, I tested it ...it must be somezhing else.. Thank's for the idea

[Ausman]

I think it's time to use the PC like I said.  You need to get on top of all the (mriad) available parameters in the actuator, have them all set correctly, and have the device working as wanted.  Far easier to first do this using the PC. 

And given the usage, for me you would set all those parameters first on the PC, and then only need a send of your control value, and a receive back of the actual physical value for checking, which is only one register each way.  In some ways an actuator like this that you are using is way too complex for what is wanted, given that it is being controlled by a PLC which can do all the whizzy things the actuator itself can do, if you write the program accordingly.

In Vision, with some comms operations there is a need to actually reset the buffer via the program.  I doubt that such a thing exists here for modbus, but just wondering......

As for the time delays, in Vision there are various ways you allow sufficient time b/n calls.  The main point is that you have to add together ALL possible times for that one call if something goes wrong, and then allow a little more.   Otherwise the system gets stuck because the next call can start when the previous one hasn't finished, due to the abnormal length of time caused by the error.  And the cycle then goes on forever.  I have to say that this is what happens in Vision, and I don't know Unistream at all, but general guidelines re modbus are fairly uniform.

[Joa]

19 hours ago, Ausman said:

I think it's time to use the PC like I said.  You need to get on top of all the (mriad) available parameters in the actuator, have them all set correctly, and have the device working as wanted.  Far easier to first do this using the PC. 

And given the usage, for me you would set all those parameters first on the PC, and then only need a send of your control value, and a receive back of the actual physical value for checking, which is only one register each way.  In some ways an actuator like this that you are using is way too complex for what is wanted, given that it is being controlled by a PLC which can do all the whizzy things the actuator itself can do, if you write the program accordingly.

In Vision, with some comms operations there is a need to actually reset the buffer via the program.  I doubt that such a thing exists here for modbus, but just wondering......

As for the time delays, in Vision there are various ways you allow sufficient time b/n calls.  The main point is that you have to add together ALL possible times for that one call if something goes wrong, and then allow a little more.   Otherwise the system gets stuck because the next call can start when the previous one hasn't finished, due to the abnormal length of time caused by the error.  And the cycle then goes on forever.  I have to say that this is what happens in Vision, and I don't know Unistream at all, but general guidelines re modbus are fairly uniform.

I think you are right. I have to find out the right settings and processes by using the PC...by that I will enter new terrain again and I have to proceed step by step.  May you have any recommodations regarding required test software(if possible freeware)?

Today I got also an information from the customer support...It seems that I was on the wrong track. The drops occur only  in the IO/  UAC RS4 struct(more related to RxTX commands like UDP or TCP) and they are not relevant in my case because I'm configured to the Modbus Protocol. In the global struct which relates to Modbus master communication there are no drops and everything is fine there. I've been told that this little problem will be fixed with the next upcomming version. 

 

Thank you all again for your time and your support!

Joachim