Mendon Systems

MrPLC Member
 View profile  See their activity

  • Content count

    490

  • Joined

  • Last visited

Posts posted by Mendon Systems

  1. Posted

    Yes, that became obvious once you explained what is going on. The number of nodes isn't a problem, but this is a combination of two networks with old equipment installed. One was set up using 192.168.0.xxx and the other was set up using 192.168.1.xxx. I think that for the moment I will stick with using the address table now that I understand why it is needed. Messing around with that old unsupported hardware would probably be more trouble than it is worth.

  4. Posted

    Well ............ from the description of the error, that's what you would think, BUT the node switches are set correctly. The PLC IP address is fixed at 192.168.1.101 and the node switch setting is 65 hex (&101=#65). The only way to get rid of the error is to go to the FINS/UDP tab of the Ethernet setup and change the conversion method to IP Address table. If it is set to any of the automatic modes the F3 error occurs. There are about 10 pages of description in section 5-2 of the W465E manual and none of it makes sense, particularly why automatic doesn't work. The F3 error does not interfere with Ethernet/IP communications to CX Programmer.

  5. Posted

    What exactly is an F3 error code on the CJ2M Ethernet port trying to tell me?? I have read the troubleshooting section in the W465E manual, but it really doesn't explain this very well.

  6. Posted · Edited by Mendon Systems

    Dunno ...... That entry should be the first word of your receive buffer (usually a D register). Maybe it's something to do with the Windows fonts. I have had a few strange things happen with Windows 7? Another thought: Maybe that word contains some non-ASCII value that CXP is trying to display?

  7. Posted

    Have you tried your system with just 1 NS terminal running??? If it is a communication load issue it seems that it should act differently with less terminals. If reducing the number of terminals makes a difference try increasing the message interval by a lot. If reducing the terminals doesn't help, try making up a test version of your program for the NS that only talks to one online PLC. Those comm timeouts may be causing the issue.

  8. Posted · Edited by Mendon Systems

    That problem happens occasionally. It could be a bad card, or a bad NS5 terminal. That is why I stopped using them. As far as I know Windows 98 is the newest system you can use that will format a memory card for FAT16. The alternative is to get a new card from Omron. I have purchased some Sandisk Ultra CF cards in the past that came pre-formatted with FAT16.

  12. Posted

    Another thing that you can use to reduce scan time is task switching. If there are blocks of code that do not need to be executed you can use task scheduling with the TKON and TKOF instructions to only execute them when they are needed. The only drawback to this approach is that your scan time can vary widely depending on how many tasks need to execute. I just finished a CP1L-EM30 program that is 7.5k with an average scan time of about 2ms. It is broken up into 9 separate tasks and 14 subroutines. Only two of the tasks execute on every scan. Section 5-2 of the CJ2 manual (W473) has a good writeup on tasks.

  13. Posted

    No ............ But I have used the CJ and CP series high speed counters. You will probably find that your pulse rate is too slow for the PLC scan time so you will have to do some programming to get accurate results. One trick is to read the counter with a scheduled task that only runs once per second and average the reads.

  15. Posted

    AND ............... check that you have the correct cable connections. The CIF01 uses Omron's pinout for the DB9 not the industry standard. You will probably need a C200H-CN220 cable to adapt your barcode reader to the CIF01.

  16. Posted · Edited by Mendon Systems

    Here are the settings and listing for the Reference task from a CP1L that I did a couple years ago. Maybe this will answer some of your questions. That "warning" you found in the manual is there because they are using interrupt task 140 in their example which shares I/O points with pulse output 0. EDIT: I should also mention that not a versions of the CP1 are created equal. I have a CP1L-EM30 here the refuses to do an origin search using the ORG instruction, but once the origin has been set it will do a reference return using the ORG instruction. I am wait for some answers from Omron on that one. Reference.pdf

  18. Posted · Edited by Mendon Systems

    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.

  19. Posted

    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.

  21. Posted

    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.

  22. Posted

    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.

  23. Posted

    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!!

  24. Posted

    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.

  25. Posted

    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