Power PMAC and serial communication

[burg0183]

I am working on a project with a power pmac cpu and a variety of cards. We have some serial devices we need to interface with the delta tau (two way communication). We have up to 6 twisted pairs to use for the physical layer and the link will be roughly 60 meters long.

 

Has anyone in the delta tau community worked on similar problems? What serial communication solutions does delta tau offer? At this time, I have considered a ACC-72E card. Is this a good solution?

 

Brett

[Omron Forums Support]

Hi,

 

A while back I wrote an app note with the help of KEJR describing how to use a USB-to-Serial converter on Power PMAC's USB1 port to talk to a serial device (in my example, it was actually a Turbo PMAC to which I was talking over serial). It's attached.

 

I never quite figured out how to use the RS-232 port directly, but I believe it's possible and I gave my notes of my progress on it at the end of the app note. I think the reason we opted not to do this is because Power PMAC dumps debug info regularly to that RS-232 port without warning (to my knowledge), so it would be hard to distinguish "real communication" from the dump. Using the USB-to-Serial method eliminates this issue.

 

KJER if you read this, did you ever get that working directly through RS-232?

Serial Communication with Power PMAC in C.pdf

Source Files.zip

[burg0183]

Thanks for the response!

 

Are there any non RS-232 options, such as RS-422, RS-485, canopen, etc?

[Omron Forums Support]

The ACC-72EX card can be used for various other protocols. Manual LINK.

 

The protocols it supports are as follows:

 

PROFIBUS-DP – Master – OPT10

PROFIBUS-DP – Slave – OPT11

DeviceNet – Master – OPT20

DeviceNet – Slave – OPT21

CANopen – Master – OPT30

CANopen – Slave – OPT31

CC-Link – Slave – OPT51

 

EtherCAT – Master – OPT60

EtherCAT – Slave – OPT61

EtherNet/IP – Scanner/Master – OPT70

EtherNet/IP – Adaptor/Slave – OPT71

Open Modbus/TCP – OPT80

PROFINET IO – Controller – OPT90

PROFINET IO – Device – OPT91

[dzrong]

I am using serial port to communication,the format is not ASCII,but Hex,datas is receive well except 0x13 ,0x0D.Also it is a linix problem,but hope helping.

 

I had try c_lflag &= ~(ICRNL | IXON);,but the problem is still there.

[Omron Forums Support]

dzrong,

 

Can you post the relevant code? It's a little hard for me to help you without more specific detail. Also, what seems to be wrong about 0x13 and 0x0D? Are they corrupted on the receiving end?

[dzrong]

The 0x13/ 0x11 /0x0D is the apecial character of Linux,0x13 is Enter,0x11 is ^Q,ix13 ^s.

So must disable the system function of this characters. This may be done though setting options.c_lflag. But I can get it out.

 

If you can help me to try that,you can send that character using serial port,and recieve it itself(only connect the serail port send pin and recieve pin),if 0x13/ 0x11 /0x0D can be sent and recieve correctly,we win!

 

I change a little code of the examle, so the serial port can send Hex,

//static const char *SampleCommand = "ver\r";

static const char SampleCommand[7] = {0X3C ,0X13 ,0X11 ,0X0D ,0X03 ,0X4B ,0X0D};

 

char msg[EXAMPLE_CODE_RESPONSE_MAX];

int ret;

 

// Initialize the serial port.

// "/dev/ttyUSB0" is where Power PMAC maps the USB-to-Serial device

// The second number is the baud rate. Here are some example baud rates:

// B9600: 9600 baud

// B38400: 38400 baud (the default for talking to a Turbo PMAC)

// B115200: 115200 baud (the default for talking to a host PC or to another Power PMAC)

 

SerialPort = OpenSerialPort(Port,B9600); //rdz

// Change your baud rate to what you need. To talk to Turbo PMAC, use 38400.

// Note: If you want to use this to talk to Turbo PMAC, I1 should be set to 1 on the PMAC to disable CS handshaking

// Otherwise, Turbo will wait until it gets the CS signal to send characters

 

//Check return code to see if the port opened properly.

if(SerialPort < 0)

{

Send(1, "Problem opening port!");

return SerialPort;

} else printf("Serial port opened properly.\n");

 

//Write out the command to read display on meter...

//ret = write(SerialPort, SampleCommand, strlen(SampleCommand));

ret = write(SerialPort, SampleCommand, 7);

 

 

thought P var,we can get the recieve value

char buf;

int i,ret;

 

if(FileDescriptor < 1)

printf("Trying to Read a serial port with invalid file descriptor.");

 

i=0;

 

double StartTime = GetTimeSec();

 

while((GetTimeSec()-StartTime) < TimeoutSeconds)

{

ret = read(FileDescriptor, &buf, 1);

pshm->P[1000+i]=buf;

 

If p1001 can be 0x13, my problem is solved.

[Omron Forums Support]

Make sure to explicitly cast anything you write to a P-Variable to double:

 

pshm->P[1000+i]=(double)buf;

[dzrong]

Because the value was 8bits data,that will be same in my application if or not have the `double`.And I had got other values expect 0x13... So that will not the key of my problem.

[Omron Forums Support]

Hi,

 

Hex and ASCII are the same thing, really. It's just how you choose to display the characters.

 

Furthermore, be really careful about your usage of capitals vs. lowercase. C is sensitive to this.

 

I am not really following your issue here and I do not think it is really PMAC-related. Please try surfing, for example, stackoverflow.com for details on serial port programming. They have many useful discussions on there.

[KEJR]

I am late to this reply but I wanted to say in reply to Dzrong that much of this code was taken from one of my system libraries that I used to query a panel meter device. For this application we only needed to query the device every half second or so and not with any great determinism. I made it into a more general purpose library call that can handle talking to different ASCII-like devices with a well defined character terminator (Some panel Meters, Turbo PMAC, Copley Amplifiers, etc).

 

The ReadResponse() is a packaged routine to read a single character delimited response and put it into a char buffer with null termination (C string). It allows you to specify a single character message terminator and a timeout so that your code doesn't hang forever if the device goes out to lunch. This is similar to the .NET SerialPort.ReadLine() method with the SerialPort timeout enabled.

 

If your response does not lend itself to having a single character message terminator (CR or LF are typical, but it could be any single byte) then you may consider writing your own byte by byte routine to read your responses. Some systems have binary fixed length message protocols for instance and this is something you would have to read, parse, and check for validity yourself after knowing the format.

 

You can use glibc read() and write() commands to access the port directly once the serial port has been opened. I packaged up the serial port open into a library call because it is quite ugly just to open a port and configure it not to act like a tty terminal. I had to do some digging to try and understand what the different options were and set the parameters for what worked for me. Feel free to modify this to your application So in short using read() and write() you can do all sorts of protocol programming with the serial port but YMMV.

 

To answer the original author's question, you can get converters to go from 232 to 422/485 hardware line levels. They might even have something akin to a USB->RS422 device now that uses the prolific or FTDI chips with RS422 or RS485 signal levels. I've found that the PPMAC assigns my USB devices consistently which makes it nice to address if you have multiple USB devices.

 

KEJR

[dzrong]

Hello KEJR,

 

Thank you for so much more and more characters reply.

I had found the reason:one character write wrong because me.

I have a more knowledge of seral port of power Pmac because you reply.