RSLogix5000 scans

drewster

Member
Join Date
Nov 2017
Location
Bothell
Posts
10
I have a question about scan configuration. If I have a ladder diagram that I want scanned more often than the main routine, where would I put it? Would it be a new task? A new program?

Thanks!
 
Your tasks are either continuous, periodic, or event driven.
There can only be one continuous task.
If your "main routine" is already in a continuous task and you want this other ladder to be scanned more frequently, then you'll need to subordinate the other logic somehow, like by moving it to a periodic task.

If you click "Help" on the New Task dialog box, there's a lot of good info in there.
 
You could also put the ladder in a 1 rung sub-routine and call the routine from 2 or more places in your program . Remember that I/O updates asynchronously to the scan and if you are using I/O it could change during a complete program scan .
Paul
 
Why do you want to do such a thing?
I can't see any real reason to do that with a PLC.
If your program is so slow you need to execute some faster, use a periodic task (and take another slowdown hit), or fix the reasons for slow scanning.
 
We're having momentary comm losses to a remote IO rack. We have a comm_fail tag that we use in the logic to jump over the rungs that read the remote IO and perform other logic functions. Sometimes, the comm loss happens during the scan of the remote IO before our comm_fail tag becomes true.
 
Working on that as well, but need to get a fix in place because all of our "Normally Closed" signals drop to 0 and valves start to close.

I have a 1734-AENT/A remote IO module on the network. Occasionally (Every couple weeks or so) we lose comms to the remote IO module for 10 - 60 seconds and we're not sure why.
 
Well, that's kind of a big deal. While you're at it, look at the ability to configure fault states (i.e. your comm failure) on each Point I/O module.
 
all of our "Normally Closed" signals drop to 0 and valves start to close.

Do you mean input signals or output signals ? In general, input data values should remain at the last known state when an I/O connection fails.

A bit of info I'll contribute; the status of the 1734-AENT can be easily determined by the AdapterName:I.SlotStatusBits0_31 tag.

When that tag is all 1's, it indicates a failed I/O connection. Because the tag is a DINT, the value of the tag equals -1 when the I/O connection has failed.

That value should be updated at the same rate as the RPI for the Rack-Optimized I/O connection, and you don't have to execute a GSV to examine it.

If you're talking about input signals going to FALSE at about the same time as the I/O connection is lost, that suggests that there's something interrupting the DC power to the adapter and to the input modules.

I have a POINT I/O adapter on my test bench with a similar setup (several always-true status signals), and now I'm curious about what happens if I disconnect the network vs. disconnect the power.
 
Input signals. I was thinking the values should hold last state.

We did a test; when we disconnect the network cable, we get the comm fail but the values remain "1". As soon as we reconnect, the values go to "0" then come back to the proper state, "1".
 
Drewster, that's exactly the behavior my test bench system gives me as well, whether I unplug the adapter or cut power to the adapter and Inputs simultaneously by opening a fuse block.

In my case, I also get the same behavior when I open the AC 3-phase disconnect and cut power to the DC power supplies. But your system might be different with regard to hold-up times and RPI values.

The input values going to zero momentarily before returning to the correct value is a typical initialization process on A-B remote I/O products.
 
Thank you Ken. Now I just need to figure out why we're losing comms (Or power?) momentarily. I will look into our battery backup/power supply for this rack. Or maybe the backplane is flaky?

I am also trying to deal with the problem programmatically, but this is more of a band-aid.

Thanks for your help everyone!
 
I've heard of this before at a previous plant.

Do you have any radio transmitters nearby the rack that fails?
Is there any trains nearby?

at one site, maintenance would switch channels and the transmitter was close to a rack. the channel was interfering with the comms.

the same was true for the train, only is got all remote I/o racks.

james
 
Thank you Ken. Now I just need to figure out why we're losing comms (Or power?) momentarily. I will look into our battery backup/power supply for this rack. Or maybe the backplane is flaky?

I am also trying to deal with the problem programmatically, but this is more of a band-aid.

Thanks for your help everyone!

As a band-aid, could you debounce state changes of these inputs to handle momentary drops?
 

Similar Topics

Hello everyone, I have an RSLogix5000 project which is running live in the factory but I need to make some changes to the logic. I want to test...
Replies
0
Views
1,097
Good Morning Everyone, I'm looking to use the GSV instruction to get I/O fault codes for my project so I know if there's a comms issue in my E/IP...
Replies
5
Views
808
The machine is running production. When trying to go online with the laptop the whole machine looses communication and faults out. Drives, HMI...
Replies
13
Views
1,867
Hello, is it possible to create a data block, something like shared datablock in Siemens STEP 7, in the RS Logix5000 PLC project? I would like...
Replies
3
Views
1,049
Hi all. This is a machine programmed by the manufacturer. There is an event task and the event tag is a MOTION_GROUP tag. Screenshot . Since the...
Replies
2
Views
978
Back
Top Bottom