Jump to content
OMRON Forums

Raw TCP stream with Turbo PMAC


KEJR

Recommended Posts

Hello,

 

We have a Turbo Brick that we want to attach to devices that can accept "raw" TCP streaming data. In our case the Turbo PMAC would send simple ASCII commands similar to what you would see on a serial port.

 

I have read in the manual that you can send data from the Turbo PMAC with a version of "send" command and it will go over TCP to another device, but that there is yet another packet/driver level (By Delta Tau) on top of the TCP layer.

 

Is there really no way to create a *unfiltered* TCP Server listening on a port that when connected will allow us to send data with our PMAC PLCs or PROGs?

 

In other words, is there a way to connect with a standard TCP client (such as PuTTY, or .NET TcpClient) and get an exact copy of the ASCII streaming data sent from the Turbo PMAC?

 

BTW, I'm wishing we did this project with a UMAC based Turbo so we could upgrade to a Power PMAC :o) It was just a year or two too early at the time we developed it!

 

Thanks,

KEJR

Link to comment
Share on other sites

  • Replies 6
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Hello,

 

We have a Turbo Brick that we want to attach to devices that can accept "raw" TCP streaming data. In our case the Turbo PMAC would send simple ASCII commands similar to what you would see on a serial port.

 

I have read in the manual that you can send data from the Turbo PMAC with a version of "send" command and it will go over TCP to another device, but that there is yet another packet/driver level (By Delta Tau) on top of the TCP layer.

 

Is there really no way to create a *unfiltered* TCP Server listening on a port that when connected will allow us to send data with our PMAC PLCs or PROGs?

 

In other words, is there a way to connect with a standard TCP client (such as PuTTY, or .NET TcpClient) and get an exact copy of the ASCII streaming data sent from the Turbo PMAC?

 

BTW, I'm wishing we did this project with a UMAC based Turbo so we could upgrade to a Power PMAC :o) It was just a year or two too early at the time we developed it!

 

Thanks,

KEJR

 

 

Sorry, there is no way to send a standard ascii stream over the Turbo PMAC's ethernet port. There is a small limited micro controller that handles ethernet on that product that was designed to simulate the prevalent interfaces (ie. ISA) at the time it was created more than a decade ago.

Link to comment
Share on other sites

Sorry, there is no way to send a standard ascii stream over the Turbo PMAC's ethernet port. There is a small limited micro controller that handles ethernet on that product that was designed to simulate the prevalent interfaces (ie. ISA) at the time it was created more than a decade ago.

 

Thank you Henry. As a side note, we are experiencing many tens of milliseconds delay when using the modbus option (50-70ms, somewhat random). We tried a crossover cable and it still had issues. We haven't pinpointed it to the PLC controller or the PMAC yet (i.e. I haven't sent wireshark loose on it yet) but now that I hear this response it points more toward the PMAC. We still might be able to do something with the modbus and have our Host PLC send the ASCII strings to our server.

 

We do have a serial port, but the data takes too long to shift out of the serial port before we get to our next machine cycle. I'll talk to my colleague to see if he might be able to trim the amount of data sent out, or if we can just keep statistics instead of raw cycle by cycle data.

 

Thanks,

KEJR

Link to comment
Share on other sites

Just as an FYI I have been using the modbus in the Turbo UltraLite controller which is probably pretty close to the brick controller. I am able to read the entire modbus memory block in under 2ms from linux on my system. The biggest problem i have seen isn't the Turbo PMAC it is the Linux computer being loaded with network traffic to other devices. I would expect that the brick can handle the same 2ms update rate i have been able to hold on the UltraLite.
Link to comment
Share on other sites

I am able to read the entire modbus memory block in under 2ms from linux on my system.

 

That is very encouraging. Can I ask how you are measuring this, and how much jitter you have on this 2ms update rate? Also, is the Linux PC the modbus master (i.e. doing the polling) and roughly how big is the data?

 

The application that we are seeing the 50-70-ms latency on is on an "industrial" switch (AutomationDirect) in a cabinet with only the PMAC and a single modbus slave that is reading/writing 16 words and 16 bits. I need to get an old school 100mbit *hub* and run wireshark on it to find out what is really going on.

 

In similar issue I'm testing the amount of time it takes to send ethernet data from a mitsubishi PLC over a switch to my PC and am seeing 200ms latency between the send and the ACK packet sent back. Beautiful!

 

Thanks for the tip Dan!

 

KEJR

Link to comment
Share on other sites

The Turbo UltraLite has 256 16 bit words of standard modbus memory. Our Linux PC reads all 256 words of modbus memory and makes a duplicate memory map in the PC. The PC is functioning as the master and poling the Delta Tau. The only trick is to make sure you do a block read of registers so they are in one data packet. We logged the system time in the PC of the the modbus requests. This allowed us to verify that we are able to get the entire standard modbus memory map back to the linux PC in under 2ms. The only issues we had are all related to other network traffic. This was an issue when we had the Delta Tau on our in house network at which point our updates where at 10-15ms. When we moved it to the machine internal network we haven't seen any issues with speed.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...