V1040 + RS485 problem

[dak]

Hello Everyone,

 

I have problem with communication between V1040-T20B and any Modbus slave.

Unitronics configuration:
Visilogic 9.7.0
V1040-T20B
Firmware 003.003.11
Boot 002.002.11
Bin library 003.010.03
Factory boot 001.003.07

 

When RS-485 is used the PLC receive the same data as it transmit. After short time it receive the correct data from the slave.
But the V1040 evaluate transmitted data as answer and produce an error. Then correct answer come but V1040 ignore it.

 

When I tried Vision 120, everything works fine. The PLC disable recieving data while the PLC is transmitting own data.

But with V1040 it does not work on both port. RS485 Termination jumpers does not help. On PLC information mode Serial monitor

is visible that PLC receive the correct data from RS485 slave, but it is visible, that it always recieve 2 packets for one transmitted packet.

Because first packet is wrong (own transmitted data) and second is ignored nothing can be read from RS485 slave to PLC MI's.

 

I see two solution for this problem:

1. There is SP3072EE chip for transmit/recieve with Read Enable pin. This pin can be used to disable receiving data during transmit.

2. Clear Receive buffer immediately after finishing transmit

 

Is it possible to solve this problem by upgrading firmware or other software way?

With best regards
David

[Joe Tauser]

Attach your program

 

Joe T.

[dak]

Dear Joe,

thank you for your reply.

Please try very simple attached sample.

Have a nice Monday
With best regards
David

rs485test.vlp

[Joe Tauser]

Thanks for posting your code.

 

First, I noticed you set up your COM port as 8,N,2 which is kind of unusual.  Typically we use 8,N,1.  I turned the number of retries and the timeout down from the defaults as it also makes things run faster.  The default timeout of 1 second is the same as your polling rate, so the PLC won't know what to do.  You also want to interlock the RHR block with the Function in Progress bit so you don't trigger another instance of the block while it's busy.  Finally, use the built-in SB 13 instead of a transitional on SB 3.

 

I've attached the program with some minor edits.  Let me know if it helps.  I don't know why it worked better on a V120.

 

Joe T.

rs485test JT.vlp

[dak]

Dear Joe,

 

thank you very much for your support. I am realy glad you try to help me with this problem.

Unfortunately your changes did not help, the result is completely the same. I realy think that problem is with receiving transmitted data. I try to describe more details.

In my example I transmit the following data (hex):
Tx: 01 03 00 09 00 01 54 08

Because RS485 is used transmitted data are going not only to the Rx of slave but also to Rx of master. During the sending the data V120 disable receiving any bits on Rx so everything works well. But V1040 immediately start to receive these data as answer from the slave.

V1040 receive same string:
Rx: 01 03 00 09 00 01 54 08

This is not valid answer for MODBUS protocol, so Status Messages MI start to show error 8 and MI where the answer should be stored is unchanged.

It is same situation if you disconnect RS485 slave - V1040 will recieve transmitted packet back and shows error 8 (instead of no communication error)
When RS485 slave is connected the V1040 receive second packet then:
Rx: 01 03 02 00 04 B9 87
This is valid MODBUS answer from slave and value 4 should be stored to MI.
But because V1040 received bad answer before this packet is ignored.
You can see small video of Serial monitor at http://clasic.cz/rs485.mov

Maybe one more interesting test when the address of MODBUS register is changed:
Tx: 01 03 02 09 00 01 55 B0

Again V1040 receive the same packet
Rx: 01 03 02 09 00 01 55 B0

Now the answer is almost correct (packet is one byte longer and CRC is wrong but first 5 bytes are fine). V1040 evaluate it as correct answer and store value 0900h to correct MI and Status Messages MI becames 0 as everything is fine. It works also without slave connected.
If RS458 slave is connected the V1040 receive second packet then:
Rx: 01 83 02 C0 F1

This valid answer from slave (slave get know about the bad register address) is ignored.
In this example V1040 acts as everything is fine even the slave can be disconnected or sends error message.

I think only solution is disable receiving the transmitted data and this is question if the firmware change can be done. I do not know if it is possible to control Read Enable pin on SP3072EE chip on V1040 motherboard. Another chance is to clear receive buffer immediately after transmitting the data or ignore all received data during transmit. I hope this problem could be solved software way.

Thank you again for your cooperation.
Have a nice Tuesday
With best regards
David

[Henny]

Dear Joe,

 

thank you very much for your support. I am realy glad you try to help me with this problem.

Unfortunately your changes did not help, the result is completely the same. I realy think that problem is with receiving transmitted data. I try to describe more details.

In my example I transmit the following data (hex):

Tx: 01 03 00 09 00 01 54 08

Because RS485 is used transmitted data are going not only to the Rx of slave but also to Rx of master. During the sending the data V120 disable receiving any bits on Rx so everything works well. But V1040 immediately start to receive these data as answer from the slave.

V1040 receive same string:

Rx: 01 03 00 09 00 01 54 08

This is not valid answer for MODBUS protocol, so Status Messages MI start to show error 8 and MI where the answer should be stored is unchanged.

It is same situation if you disconnect RS485 slave - V1040 will recieve transmitted packet back and shows error 8 (instead of no communication error)

When RS485 slave is connected the V1040 receive second packet then:

Rx: 01 03 02 00 04 B9 87

This is valid MODBUS answer from slave and value 4 should be stored to MI.

But because V1040 received bad answer before this packet is ignored.

You can see small video of Serial monitor at http://clasic.cz/rs485.mov

Maybe one more interesting test when the address of MODBUS register is changed:

Tx: 01 03 02 09 00 01 55 B0

Again V1040 receive the same packet

Rx: 01 03 02 09 00 01 55 B0

Now the answer is almost correct (packet is one byte longer and CRC is wrong but first 5 bytes are fine). V1040 evaluate it as correct answer and store value 0900h to correct MI and Status Messages MI becames 0 as everything is fine. It works also without slave connected.

If RS458 slave is connected the V1040 receive second packet then:

Rx: 01 83 02 C0 F1

This valid answer from slave (slave get know about the bad register address) is ignored.

In this example V1040 acts as everything is fine even the slave can be disconnected or sends error message.

I think only solution is disable receiving the transmitted data and this is question if the firmware change can be done. I do not know if it is possible to control Read Enable pin on SP3072EE chip on V1040 motherboard. Another chance is to clear receive buffer immediately after transmitting the data or ignore all received data during transmit. I hope this problem could be solved software way.

Thank you again for your cooperation.

Have a nice Tuesday

With best regards

David

Hello David

 

How about turning on "flow control" in the com port init?

 

Here is a link that explains flow control in more detail.

http://www.moxa.com/resource_file/509820091121333.pdf

 

The Port pinout is the same in both a V120 and a V1040 but as you already wrote it seems like the V120 handles the RS485 communication differently than the V1040.

 

So perhaps the Flow control setting in the "com init" is worth a trial?

 

Otherwise I hope for you that Joe has another good idea.

 

Regards

 

Henny

[dak]

Dear Henny,

thank you very much for joining this thread and for your idea.
Unfortunately setting the Flow control does not help. I tried this setting

even I do not use RTS/CTS wires (the settings can influence something

else if there is software mistake) but the V1040 still receive transmitted

data.
On the motherboard there is used chip SP3072EE (Sipex) for converting

the RS232 signal to RS485. As you can see on attached picture
receive and transmit unit is connected inside the chip and only A and B

pins are available. Therefore it is correct that you automaticaly receive

the transmitted data. To eliminate the problem there is pin RE (read

enable - negative) on the chip. This way is possible to control (disable)

receiving data to the buffer.
On V120 controller is different hardware solution and SP3072EE chip

is not used.

Thank you again for your post.
Have a nice Tuesday
With best regards
David

[lawry]

Hello David,

 

I think you ought to change the Slave id from 1 to any other integer between 2 and 254. Your Master already has ID 1

 

Ron

[Henny]

Hello David

 

Ok the flow control doesn,t work.

The slave and master address should be different as Lawry mentioned (didn't notice it) so it's good that more people look into your problem.

 

If changing the id numbers doesn,t solve the problem you could check the RS232/485 dipswitch settings because

you mention jumper settings but if you read the installation guide from V1210(it's also with a V570)
(Can’t find one from V1040) then these settings are carried out by means of 6 dipswitches

http://www.unitronics.com/Downloads/Support/Technical%20Library/Vision%20Hardware/V1210%20-%20Installation%20Guides/V1210-T20BJ_INSTALL-GUIDE_03-14.pdf

 

When you read the visilogic communication manual

http://www.unitronics.com/Downloads/Support/Technical%20Library/VisiLogic%20Software/Software%20Manuals/VisiLogic%20-%20Communications.pdf

At page 15 jumper setting JP1-4 are mentioned for the V120 and perhaps also some other models?

 

 

 

 

Joe also mentioned the port settings 8 N 2 are unusual and that mostly 8 N 1 is used but here is a link to a document

http://support.ctc-control.com/customer/techinfo/docs/5300_951/951-530021.pdf

and at page 10 you can see that 8 N 2 is not unusual for modbus RTU with RS485

 

I,m still wondering why the communication worked on a V120 with master and slave both having the same ID?

 

Regards

 

Henny

[dak]

Dear Joe, Henny & Ron,

thank you very much for your help with solving my problem. I realy appreciate your time and effort you spend with this thread.
At the same time I feel very bad to initiate this topic, because the problem was cable...
I used less than 1 m long UTP cable CAT5 for connection between PLC and inverter.
Also before starting this topic I checked the cable and everything was right.
Today I tried to start again from the zero. I used new cable CAT6 0.5m long and everything works well.
I checked again pins on the old cable and everything is right but this cable does not work.
The only difference is that I connected only pins 1 and 6 on the PLC. On the older cable all pins were

connected but pins 2-5 were not use on side of inverter.
So there can be problem with some interference on unused wires and V120 is probably more tolerant

to this interference...

In any case I would like to thank you again for your time and fine ideas. Please sorry to take your time.
But maybe somebody sometimes can utilize this solution...

With my best regards
Have a fine Wednesday
David

[Henny]

Hello David

 

Good to hear that your problem is solved!

 

I'm curious about the master and slave addres Ron mentioned,did you have to make changes in your program at this point or was it only

the cable?

Did you use your initial com port setting 8 N 2 of the 8 N 1 setting Joe purposed?

 

I'm only asking this for learning purposes

 

Kind regards

 

Henny

[dak]

Dear Henny,

thank you for your reply. I found the problem in cable before trying same address of master and slave.
But I try this later because I was interested why this setting should not work. Generaly the master ID

is not use in MODBUS protocol. Master only sends requests to the slaves with address 1-247 and they

reply with their address.

But there can be probably problem when PLC becomes slave for "new" master PLC or PC in MODBUS network.
Then new ID must be set to avoid conflict with ID of other slaves.
For sure I tried to set both (PLC and invertor) with ID #1 and there was no error for 10.000 requests.

Initial com port setting: I tried both setting 8N2 / 8N1 and both settings works well. The devices are probably
tolerant to this setting... But when I changed the inverter to 8E1 then 8E1 must be set in PLC (8E2 receive

corrupted data, 8N1, 8N2, 8O1 and 8O2 receive nothing). The same situation is with 8O1.

I hope it can help little bit, please feel free to any another question.

With my best regards, have a nice weekend
David
 

[Henny]

Hello David
 

Thanks for your explanation!
 

Will the communication between your inverter and the V1040 automatically be reestablished when your repower your inverter?
 

I ask this because we use Wago remote I/O (Modbus udp protocol) with a V230 in one installation and in another installation a V570 is used for this purpose.
If the Wago remote I/O is repowered with the V230 then the Modbus config FB has to be retriggered before communication will be established again.
The V570 has no problem in such a situation and only the SB2 bit is needed before the comport and protocol setting.

 

Kind regards
 

Henny

[dak]

Dear Henny,

 

thank you for your message. I tried repower inverter and everything seems right. I do not need to reestablished Modbus config.
I tried also disconnect RS485 wires many times and everything works well. I use Mitsubishi FR-D720 inverter with Modbus RTU protocol.
Unfortunately we use only V120, V280 and V1040 units and RS232/RS485 devices so I cannot try your configuration.
I never tried Modbus IP protocol so it is difficult to help with your strange problem. I looked at Wago documentation and

there should be possible to use Modbus TCP protocol, which should be more reliable but slower... Can it help you?

With my best regards
David

[Henny]

Hello David

 

Thanks for your reply!

 

It’s not a big issue with the V230 but I run in to this and learned the trick about retriggering the Modbus config FB from our Unitronics supplier in the Netherlands and that is a good workaround.
On the same V230 is besides the Modbus ip UDP protocol also  Modbus RTU over comport 1 running using RS232 and this connection is automatically reestablished when dis en reconnecting cable.
The V230 is also Modbus master at the Modbus RTU connection.

 

With a spare V570 and some Wago remote I/O I also tested as you suggested with Modbus TCP but therefore the logic is a bit more complicated because you have to make use of the socket init and the socket connect functions. Also SB147-149(depending on socket number in use) has to be used as a condition for the Modbus reading or writing FB,s.I learned this from the Unitronics Ethernet webinars.

When repowering the remote wago I/O for let’s say 10 times  6 times communication was automatically reestablished and 4 times I have to repower the V570 to reestablish communication.
With some extra logic added it worked always but then the advantage compared with modbus udp regarding this particular issue is completely gone so I leave the communication at modbus udp for this moment.
Don’t know how this behavior is with a V230 because I don’t have a spare one for testing this.

 

I find the Unitronics great plc,s with a lot of value for money when compared to leading plc manufacture companies like Siemens,Rockwell etc.Unfortunatly in my country almost every plc programmer knows the Siemens and Rockwell plc,s but never heard of Unitronics and everyone seems to be used to paying a lot of money for programming software?

 

Regards and thanks again.

 

Henny