CP1L-EM30 serial port

[Mendon Systems 22]

I have to implement a fairly complex serial protocol on a CP1L-EM30. Everything works fine EXCEPT getting the receive side of the serial port started (RXD instruction). I am using serial port #2 (for CJ2M compatibility) set for 9600,N,8,1 and RS-232 mode with a Cr/Lf terminator. I have a Digilog data line monitor in the line to verify what is being sent both ways. The first several times (it's not consistent but typically about 3) after the CPU is started I get the Receive Ready flag (A392.06) with a character count (A393) of zero and get nothing from the RXD instruction. Once it wakes up then everything works fine. I have tried time delaying the RXD instruction after the Receive Ready and various combinations of the Port Reset (A526.00) but so far nothing seems to solve it. Anyone got any ideas??? This is becoming really irritating!!

[PMCR 66]

Can you post the snippet of the code for the serial comms? I can troubleshoot on my end.

[Mendon Systems 22]

Here's the current version of the program and a copy of the protocol spec. I did discover that it seems to work OK when I cycle power to the PLC. The problem seems to occur when switching between Program and Monitor modes or when doing an online edit with CX Programmer. CP1L Test Program.zip Serial Comm Protocol.pdf

[Mendon Systems 22]

I believe that I found the problem. The timer on line 3 of the COM_Handler was set too short. It's OK when working with the host computer, but it was too short for manually typing in the commands.

[PMCR 66]

Interesting. Are you using a terminal emulator that sends character at a time, or line by line? SuperMon sends line by line, which may help on the emulation. http://forums.mrplc.com/index.php?app=downloads&showfile=575 Here are a few other things that I have noted. 1. In Com_Handler, you have a P_First_Cycle executing an @Set. This will never execute. The @ requires a rising edge, and the First Cycle flag by definition has no rising edge, only a falling edge. I doubt that has anything to do with what you are seeing, but it will not reset the port on startup. 2. When you execute the RXD, you are reading &255. I would recommend reading a size of A393 instead. With Supermon you can also send multiple strings at once (see pic below). SuperMon.bmp

[Mendon Systems 22]

Yeah on both of those. I had the reset running off of the startup timer originally and was using A393 for the read count. I took both of them out while experimenting! Thanks for reminding me to put them back. I suspect the port reset is just excess baggage, but it was put there to get rid of any junk that might be in the input buffer on a restart of the CPU. I am using plain old Hyperterminal to test. I will definitely try out SuperMon! Thanks!!

[Jay Anthony 118]

PMCR is too modest. He is the author of this awesome tool called Supermon. If it's a serial port, he' s seen it all and done it all.

[Mendon Systems 22]

Well .............. It seems to be working fairly well now. The only really WEIRD thing that I had to do is prime the transmit buffer on startup. The PLC would not transmit the first string after it was powered on. I got around it by triggering a TXD with nulls in the transmit buffer when the startup timer expires. That fix works, but I don't have a clue why it should need to be there. SuperMon doesn't seem to like the COM ports on my notebook (Startech PCI express card on a Dell Inspiron). I have not been able to make it transmit or receive anything so I went back to using Hyperterminal and the freebe version of CommFront's 232Analyzer.

[PMCR 66]

Dick Sorry the SuperMon did not work. It does have some limitations, as it is a VB6 project. It is strange that you have to send NULL characters out the port. I have never had to do that. Attached is a simple echoback program. Whatever comes in the port (as an entire string, marked with a terminator) is sent back out the port. It shows the way that I handle port resets. Could you try this in your PLC to verify basic operation and cabling? Note: The ethernet port is not setup to match your settings, so the comms setup does not match yours, and the Ethernet port setting in the project does not match yours. Do you have RTS / CTS jumpered on the CIF01? (pins 4 and 5). Port 2 Echoback.cxp

[Mendon Systems 22]

I'm using a CN220 cable, so 4-5 is jumpered at the PLC side. I don't think it's a hardware issue in that sense because it is only the very first transmission after the PLC is started that doesn't go out of the port. After the first one it works fine every time. Doing a TXD with nulls seems to always work, but I've never had to do anything like that with the CJ's comm ports. This is the first time that I have tried anything this complex on a CP1 processor serial port. There are a couple other spooks in this new CP1L-E hardware also. Apparently Omron has elected to change the FINS/TCP Ethernet protocol slightly so my HMI refuses to connect to it. CX Programmer Auto-Online uses "CP1L Ethernet" to connect to it. (whatever that is?) I have my HMI hooked up on the other COM port (1) and it periodically locks up on restarts also. Probably the same or a related issue, but there won't be an HMI on the final product so at this point I really don't care much.

[PMCR 66]

As far as Ethernet, I am not aware of any FINS differences for the CP1L-E, other than a few new FINS commands. The 'Direct Connection' feature is an addition to the Ethernet functionality that allows you to connect directly to the PLC without knowing the IP address. This is done by using a Multicast IP address. This was done because the USB port was removed for the CP1L-E, and the user needs a quick way to be able to connect directly. I suspect that the reason your FINS/TCP program will not connect is that the node number in your project is 0. Change this in the Settings, so that the node number is the same as your PLCs last octet of the IP address, and I suspect it will work for you. Cycle power after changing this setting.

[Mendon Systems 22]

I suspect you are correct about the node number. I will try that and see what happens. I wonder how CX Programmer manages to get around that???

[Mendon Systems 22]

The serial port stuff seems to be working very well now. I have managed to pack that whole protocol into about 4k steps with no compiler warnings. The whole object is to make that protocol into re-usable code for multiple applications. I have tried several different settings in CX Programmer but still cannot get anything else to connect through the Ethernet port. I have not found anything in the settings in CX-P that is the functional equivalent of the node switches on the front of the CJ2.

[PMCR 66]

Dick It is a software setting in 'Settings' , on the 'Buit-in Ethernet' tab. Set this to '101' to match the last octet of the IP.

[Mendon Systems 22]

Yep, that's the first thing that I tried. No luck! EDIT: I finally did get it to work tonight. It turns out that the node number setting doesn't matter. Edited 21 Feb 2013 by Mendon Systems

[PMCR 66]

The Node number does not matter if you specify node 0 in your FINS command, however this format would never allow you to route through different levels of FINS networks. If you specify the Node Number of the PLC in your FINS command, then you need to set the Node Number correctly.