Expansion and/or DeviceNet I/O update times on a SLC

[robertmee]

Question:

I have a 100ms (duration) pulse that I need to sense in a SLC 5/04. It is currently running 20ms scan times so on local hardware Inputs wouldn't be a problem. However, the 10 slot rack is full of all AC I/O modules (with the exception of one DN Scanner) and I need to sense these 100ms pulses (8 of them) from a solid state DC source.

Options: Add flex I/O vis DN or add an expansion rack. My concern is how are DN or Expansion I/O updates handled?

Expansion: I would assume (maybe incorrectly) that since it is a hard bus connection from Rack to Rack, the I/O is handled the same as if it were on a local rack. If so, that would probably be the safest bet.

DeviceNet: Does the Adapter/Scanner combo buffer the I/O? Or do I have to add the overhead of getting the I/O to the SLC image table to the overall update time? I don't care if the pulse is delayed by Xms, but I do care that it remains 100ms in duration. Well, not even a perfect 100ms, but a duration such that I would NEVER miss a pulse due to scan/update.

 

[panic mode]

since the CPU scan time is already 20ms (and probably not going to change much) the local I/O is not important. the question is what do you have on devicenet?


also since we are talking of only 8 DC inputs (sensors?) you could use pulse stretching inline adapters. some of them are DIN-rail mounted (like baluff BES 516-IV 2) while others are simply inserted between sensor and cable (or replace cable).

 

[robertmee]

I'm in the preliminary discovery stage right now and all I have from the customer is the RSS program. I don't have the DN file so I don't know. But judging from the PLC code, it looks to be about 168 words of DN info coming in.

 

[Ken Roach]

The safe bet is to use an expansion chassis. All SLC-5/0x controllers will control up to 30 slots in up to 3 chassis connected with backplane extension cables. As you add slots to the SLC backplane, the I/O scan time goes up a little, but it's generally negligible (in the 1-2 ms range). Expanded chassis are addressed and scanned exactly the same as the chassis that holds the controller.

On DeviceNet, the variables of uncertainty increase. The 1747-SDN's first 32 words are part of the normal I/O scan, but any words in the "M-files" are copied using logic to the SLC data table and take a little time. The 1747-SDN scan is asynchronous to the SLC scan, so you end up doing little "worst-case" calculations when you get into the 1 or 2 scantime domain.

Unless your DNet is extremely busy, I doubt you could miss a 100 millisecond input pulse.

I'd go with an expansion chassis, but also take the time to examine the DeviceNet configuration to see if you can optimize it. I just optimized a DeviceNet that was taking 50 milliseconds to scan down to about 10, using change-of-state connections and stablizing the signal so the network could handle 500 kb/s.

 

[robertmee]

The safe bet is to use an expansion chassis. All SLC-5/0x controllers will control up to 30 slots in up to 3 chassis connected with backplane extension cables. As you add slots to the SLC backplane, the I/O scan time goes up a little, but it's generally negligible (in the 1-2 ms range). Expanded chassis are addressed and scanned exactly the same as the chassis that holds the controller.

On DeviceNet, the variables of uncertainty increase. The 1747-SDN's first 32 words are part of the normal I/O scan, but any words in the "M-files" are copied using logic to the SLC data table and take a little time. The 1747-SDN scan is asynchronous to the SLC scan, so you end up doing little "worst-case" calculations when you get into the 1 or 2 scantime domain.

Unless your DNet is extremely busy, I doubt you could miss a 100 millisecond input pulse.

I'd go with an expansion chassis, but also take the time to examine the DeviceNet configuration to see if you can optimize it. I just optimized a DeviceNet that was taking 50 milliseconds to scan down to about 10, using change-of-state connections and stablizing the signal so the network could handle 500 kb/s.

Great Info Ken! Thanks!!