Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
UMAC and host computer connection over Ethernet
#1
I have an existing application where UMAC communicates with host computer over Ethernet over 100 meters distance through a couple of Ethernet switches. The host application uses PCommServer drivers.

After several months of observation, it is observed that there are data breaks in the Ethernet link on rare occasions. In host software, I am checking for interruption by sensing an unlikely set of field input values. In case of interruption, I am closing the communication by the call PmacDoc.Close(0) and then trying to re-open the communication by the call PmacDoc.Open(0, pbSuccess). When the opening call is a success, the host application resumes its work. Sometimes it so happens that host application has to close without issuing a PmacDoc.Close(0) call.

In this process, it is observed that after a few days involving a few data breaks, UMAC is "holding" a TCP/IP connection even if the host application is not running. Observation is, UMAC communication works ok upto 4 TCP connections. When UMAC holds up all 4 connections, PmacDoc.Open(0, pbSuccess) fails even if ping is a success.

Then the only alternative is to switch off the power to UMAC and then to switch it on again.

To avoid this scenario, I would like to know if there is a command in PCommServer command set for releasing all the TCP/IP holdups. Maybe there is a command for graceful closing the communication which includes releasing all the holdups.

I know some devices having TCP/IP communications having "reset" port. A connection to this port results into release of all the connections including the connection to reset port itself.
Reply
#2
Have you tried killing the PCommServer process and restarting it, rather than cycling power on PMAC?
Reply
#3
This is probably a result of handle in Pcommserver not being released. The only way to release these resources is to close pcommserver.
Reply
#4
I have tried killing PCommServer, but it does not help. Even if I re-cycle power to the host computer, UMAC keeps holding the TCP connections.
Reply
#5
Special PMAC Modbus programming control is provided in the form of the PMAC READY and CMD List Disable bits. These bits provide some control in a PLC of the PMAC Modbus operations. The READY bit when reset stops Client command list processing and as a Server sends out a BUSY error over the Modbus/TCP. This bit is mainly for control by the firmware for such commands as a SAVE or the $$$ type commands. PeWin communication to PMAC will cause this bit to be set back to the READY state even though the user may have reset it in a PLC. The CMD List Disable when set stops Client command list processing and when reset, the CMD List are reread into the USB/Modbus processor. This may reset all the sockets in the PMAC.
The location of these bits are the following:
TURBO: PMAC_READY ->X:$FFFFC2,3 ; CMD List Disable ->X:$FFFFC2,4
PMAC: PMAC_READY ->X:$FFC2,3 ; CMD List Disable ->X:$FFC2,4
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)