tmeyer

MrPLC Member
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About tmeyer

  • Rank
    Newbie

Contact Methods

  • ICQ 0
  1. I am new to the Unity Pro software/Modicon M340 processor (previous experience with AB). Does this processor have an instruction for a retentive timer? All I can find is a TON instruction, which resets when the input is removed. I would like a timer that holds its time unless specifically reset (an RTO timer in the AB world). Any help would be greatly appreciated. Tony
  2. Thanks for the input. I added the new chassis and the 1734-ACNR to the network this weekend and had no problem with the scheduling of the controlnet network. But had the *?!%*%# time getting the 1734-ACNR to see that it had 3 ASCII modules in the rack. After about an hour of frustration trying to get Rsnetworx to set the rack size (you know...the software to configure the network!), I found that you have to tell the 1734-ACNR what its rack size is, through the RSLogix5000 software. There is a "Chasis Size" tab in the modules properties with a button to "Set Chassis Size in Module". After I did that everything was good. Anyone know the logic for this? Doesn't seem right that I couldn't set the rack size with RSNetworx. Thanks again for all the help, I definately know more about controlnet and its scheduling now. Tony
  3. Thanks for the reply $ The overhead time slice is set at 40%. There is a Cimplicity application accessing the PLC data for a HMI and product destination responses. We are not sending messages to the Cimplicity; the Cimplicity is looking at and writing tags in the PLC for HMI, barcode info, and real time destination responses over ethernet. I assume this is all considered unscheduled communications? Do these communications affect the Controlnet network scheduling? Is there a way to schedule the controlnet network offline with RSNetworx to verify that it will schedule online? Tony
  4. Thanks for the reply Keith. It took some hunting, but I found some info on the number of connections per nut for a 1756-CNB. According to the chart, a 5ms nut should allow 11 connections per nut. I also saw that the maximum amount of data that any node can transmit in a scheduled communication is about 477 bytes (521 minus 44 overhead). Each ASCII module should have been transmitting no more than a 100 bytes so I'm still stumped. Thanks, Tony
  5. A customer has a network consisting of a 1756-CNB/D residing in controllogix 17 slot rack with 1756-L62 PLC. The 1756-CNB is connected to a 1734-ACNR with 5 - 1734-232ASC/C ASCII modules (Rack A), and another 1734-ACNR with 1 - 1734-232ASC/C ASCII module (Rack B). The NUT for this network is 5ms and the RPI for all the ASCII modules was 50ms. I was having trouble getting a barcode fast enough from the Rack B (higher conveyor speed than at Rack A's barcode scanners). I lowered the RPI for the Rack B ASCII module from 50ms to 10 ms, rescheduled the network (saved file) and the problem was solved. Then I went back to try to lower the RPI's for Rack A's modules to 10ms just for consistency sake, and could not save the controlnet file. I had to put Rack A's modules back to 50ms and it saved just fine. In reviewing how the RPI and NUT work in scheduling data transmissions, I cannot see a problem with all have a 10ms RPI (total 6 modules). Each ASCII module was configured for 54 Input bytes, and 20 output bytes. From what I can see, the network should have been able to transmitt 2479 bytes of data per a 5 ms NUT. I have to add to this network another 1734 rack (with 3 ASCII modules) plus a 7 slot rack (with a 1756-IA16 input module and a 1756-DNB devicenet module). If anyone has any insights into why lowering the RPI's to 10ms didn't work, I would greatly appreciate it. Thanks, Tony