9 replies to this topic

[robbudge]

Ok
Am i going mad, i have been fighting this all day,
I have restructured my PLC Address to provide a consistent string of registers, and changed my offsets.

When Looking at the comm monitor & wireshark, the communications are flaky,
with regular 'Port Locked'

WireShark reports a occasional 'TCP Retransmission' from the PLC  forcing a 0.2 second delay is the monitoring.

But the original packet arrived at the DAQ Machine Correctly??

When DAQ attempts to Write to a register if i get the timing wrong , Lock up in a endless 'Port Locked' Loop
and have to shutdown to restart the TCP Connection.
As if DAQ Tries to perform an instantaneousness Write irrelevant that the port is active.

Also when looking at the Comm Monitor the same Block of Data is requested in succession as if queued up.

The PLC is a High Speed Motion controller with a good response time and has in the past handled far more tags > 1000 with an update of 0.1 Seconds. Utilizing 4 Simulations TCP Connections.


Any Ideas?


Thanks.

One option is the disable polling before running any sequence that writes, but due to the number of tags this may be painful:(

Attached Files

•  Channel_Config.zip   1.99K   119 downloads
•  Comms.pdf   196.45K   161 downloads
•  WireShark.pdf   917.84K   312 downloads

[AzeoTech]

If your device can handle four simultaneous connections, have you considered using them in DAQFactory?  You could put all your reads on one connection and all your writes on another.  To do this, simply create two Ethernet (TCP) connections.  They'll both have the exact same IP and Port, just give them different names.  Then create two devices, selecting the new connections both with the same protocol.  As far as DAQFactory is concerned, it will think its connecting to two different devices, and so comms on one won't block comms on the other.  As long as the hardware can handle it, this should work quite well.

[robbudge]

Opening Multiple Connections is just a work around that is possible,
When looking at the activity of the TCP Connection it does not appear that we are anywhere close to the transmission limit,

And idea's how to re-set the Port-Locked problem???
And what is actually causing it ?

[robbudge]

Could it be that i need to find away to throttle back the TCP connection on the PLC,
The PLC is fast and runs 10 Tasks simultaneously with a scan time of 1ms

Even with a very basic poll i have the same problems

The 'TCP Retransmission' is a result of the source device not getting an receipt acknowledgement from the destination device, is this produced by the destination hardware (in that case why does wireshark see it) or is it produced by the destination software, and that the Modbus TCP Driver DAQ is utilizing is simply busy and missing the response ??

This is a new upgraded project that we OEM, our existing HMI is a custom coded VB interface and our thoughts are that DAQ would allow us some more flexibility.
The port lock up is a concern especially is we can't re-set or avoid the problem

Attached Thumbnails

• 

[AzeoTech]

Its hard to say what's going on without seeing it, and perhaps it'd be best for you to contact us directly and we can connect in and look over your shoulder.  A few points:

1) you can clear out a port locked error that is stuck by simply doing device.mydevice.unlockPort(), but this shouldn't be needed if things are working correctly.

2) part of the port locked problem may be because you are polling at different intervals.  This puts the queries on different threads.  My recommendation is to poll everything at the same data rate, especially since the device can handle it, and then if you want slower data, either average it, or use the # Hst to have the history only update every nth data point

3) DAQFactory should have no issue keeping up with your PLC.  In fact, DAQFactory is sometimes too fast for some devices and thus the reason we have the SetDelay() function for RTU.  Since you are on TCP, the Windows TCP driver is going to queue the data, so even if DAQFactory is busy at the instant the data comes in, Windows will capture it.  While the serial queue is pretty small, the TCP queue is large.  Remember, just browsing a website is going to pass a LOT more data than your Modbus queries.  Since its all queued, DAQFactory isn't going to miss any responses.

4) the retransmission: I'm unclear on your setup.  You have a PLC that is then communicating with other devices?  Or is it just DAQFactory and the PLC?  Retransmission of this sort would be handled completely by the hardware and is outside DAQFactory.  Its built into the TCP protocol since its a guaranteed delivery protocol.  It is unusual that you would get this if DAQFactory and the PLC are the only things on the network.  There just isn't a lot of traffic to cause this.  You may have a wiring issue.

5) what is the timeout setting on your TCP port in DAQFactory and are you getting Timeout errors?

[robbudge]

All fixed with the Help Of Matt, Thanks.

I think Mat will update

[robbudge]

With The 'Port Locked' Alert

Is it possible to Detect the 'Locked Port'.

I am Now communicating to 3 Different TCP Devices,
And would Like to Know 7 Detect Which Device is slow or Producing This Error??

[AzeoTech]

You can detect it in script if you are calling modbus commands directly.  If you are using channels, you'd have to use the OnAlert() sequence event as described in the help.  Unfortunately, I doubt that will tell you much given the speed at which you are running the system.  Are you still having problems?

[robbudge]

From Speaking with the Device Manufactures it can Support 64 Simultaneous Connection.
So i have created a Dynamic Sequence that reads the Tag Structure from MySql, and then Configures the channels in Groups

The Device has 10 Control Groups, so first we configure 10 Ports,
Then 2 devices for each port 1 Reading Channels and 1 Writing Channels.

The script then populates the reading and writing channels.

In Addition we create 2 more devices Controller_Read & Controller_Write for main controller Varaibles.

so in total we configure 22 devices and 11 ports.

The control group channels are at the moment only read tags (about 10 Dwords) with a update of 0.5 seconds.

Each group uses at own port and has the same offset.

the controller_Read channel has again it's own port and is about 100 Dwords with an update of 1 second.

When i configure the system to read only say 2 groups and the controller tags all appears fine.
When i enable the 10 groups it all goes pear shaped.

I will have alook at the OnAlert, to see if it's a specific group or if it's random.

[robbudge]

For some Strange Reason Setting the Offsets on all channels to 0.0 appears to have helped.
The offsets were staggered by group, group 0 offset 0.0 group 5 offset 0.5 in an attempt to spread the processor loading.
It looks like that caused more problems.