Charlie Maher

MrPLC Member
 View profile  See their activity

  • Content count

    16

  • Joined

  • Last visited

Posts posted by Charlie Maher

  6. Posted

    I had a project using a Dell server 2003, compactlogix and RSView32. The OPC was (I think) from software toolkit? The longer the system ran, the more OPC tags would vanish. Nothing would fault out, but the RSView devices would start being greyed out on the screen. If the end user re-boots the computer once a week, everything functions normally. The person who did the RSView program, said he looked into it and AB didn't support the Server 2003, at least at that time. You may want to see if the AB supports the server class windows?

  7. Posted · Edited by Charlie Maher

    "The existing logic consists of: Training logic" Is this logic to train the merge how long the run-out timers should be for each lane to clear out the last box released? If you are going to the effort to re-write the logic to solve merge issues, I would also add two photoeyes to act as jam detecs at the merge points on the second two conv's. This makes your runout timers more accurate and any jams you do have, less of a pile up. It currently looks like you don't have any jam detect PE's. Which surprises me if they were serious enough to write 241 rungs of code.

  8. Posted

    Bob is right, it starts out as one of those "all you gotta do is..." tasks. There are a lot of variables to play with. Then give the lanes different priorites. Or after a lane times out for lack of product, use the timeout value as part of the clear out timer for the next lane. I can get my hands on a pretty fancy 3 to 1 program, but not until Friday. To be honest, they are fairly hard to follow if you didn't write it. Mine makes perfect sense to me, but my boss hates it.

  11. Posted

    Ken, Can you describe your setup a little more, where you have a 20 msec reply. The TPD was resending the msg if the CLX didn't reply within 55 msec. They provided newer firmware the waits longer before timeout. I now do have the two talking and the PLC2 mapping is working. Do you know if the CLX mapping creates delays?

  12. Posted

    Ken, I spoke with the TPD manuf'r and they are addressing it as a decimal number ranging from 0-1263. After looking at their message format and the DF1 manual, they appear to be using the PLC2 format. Just like you said. After a day of testing with DockLight and other utils, it seems that the CLX ch0 is not replying quickly enough to the first message, so the TPD is resending it again and again.... I am in the process if getting updated firmware for the TPD to see if slowing it down helps. Thanks, Charlie

  13. Posted · Edited by Charlie Maher

    Ken, I have attached the screen shot with the DFCM settings. This was the startup size of registers, which contained the 'whole' data amount. This large amount was used to pass config data to the TPD. After the config was accepted, the read and write register counts where changed to 200 each still starting at 0 & 600. This was an effort to reduce tx/rx times. I am working on you other suggestions, and will reply with info. The Manuf'r did state that the messages were PLC5 typed messages. Should I be able to read these as PLC2? I thought the header or addressing units were different between the types? Thanks, Charlie

  15. Posted

    Full Duplex, which I have CLX setup for DF1 Point to Point I had one in BCC and one in CRC, now both are in CRC and the 422->232 converter TX & RX lights are blinking crazily. The TPD is writing to decimal address 0 thru 455 and reading from 600 thru 1263. Which is a throwback from the Prosoft's internal database structure. I have tried several mapping versions using the 0 & 600 for the file#, but that isn't working. I am guessing this is where the problem is. I did download the Docklight, and hooked directly to the TPD, I am getting DLE and ENQ over and over.

  16. Posted

    Hello, I hope someone can assist on this. I have a Logix 5561S safety PLC and a third party device (TPD) that is communicating DF1 protocol RS422. The TPD is the DF1 master and the CLX is the slave. This was working through a ProSoft serial in-rack card, but the transfer rates were deemed too slow. The task is now to try the same thing through the CLX serial port. I have a 422->232 converter and the TX & RX lights show activity, so I feel it is working. My question is....How do I map the data that is trying to arrive via DF1 into a CLX. I am trying the PLC-2, -3, -5/SLC Mapping function, but I think the TPD is addressing the data to a decimal # not a file #. I have been trying various combinations and settings of MSG and get errors on the MSG. The TPD maker states that the device is doing PLC5 typed read/write. I am stuck, none of the MSG settings seem to do anything different. Thanks in advance for your comments, Charlie