Studio 5000 JSR Question

Currently, I have a 1769-L36ERM that is being using to control a machine with 15 servos. Due to the nature of the process, the code is very intensive in calculations and conversions that are then passed to the various drives for motor control. Obviously, this is very process intensive. I have been looking for a way to reduce the size of the code that the PLC has to process, and came across the following: up to 25% of the code is just initial calculation that are part of the main routine. Most of the rungs have tied to them the same bit to turn them on for. My question is this. Could I put most of these into a JSR that the internal bit then triggers as needed? If so, would that speed up processing time?

I expect it would reduce the scan cycle time. Each instruction uses up some CPU time even if its input rung is False. Rung and branch logic also uses up time. Evaluating that internal bit once per scan cycle instead of many times every scan cycle, at the cost of adding a single JSR with an input rung that if False on most scan cycles, would save time.

One issue of moving those initial calculations to a separate routing would be the need to write to tags that are globally scoped.

Unrelated to this, if timing is an issue and the calculations are not already in periodic task(s), you might want to consider that option, so you can control the cadence of calculations; perhaps some calculations can be performed less frequently.

Curious, what is the current scan time and what do you need it to be?

drbitboy said:

One issue of moving those initial calculations to a separate routing would be the need to write to tags that are globally scoped.

Click to expand...

Only if the separate routine is also in a separate program.

Drbitby

Thanks for reminding me about the global tag issue. As for the tasks being moved to periodic, the only time these calculations are performed are at an user request.

dmroeder, I will have to go back and double check these numbers (I don't have access to the computer the program is on at the moment) but 100 ms is what the main task is set for. There are also a series of periodic tasks that actually control the motion of the servos that are set at a much faster rate.

The whole purpose behind this is that I would like to add a few extra rungs to allow for additional discrete outputs to be added to the system and an additional set to allow for the motors to be moved to other positions at certain times. However, when I attempt to even add one more output to the program, the system will lock up at some point.

I would love to be able to justify upgrading to a faster PLC (perferably a Controllogix) but the original program is so mixed up that I need to fine tune that first.

You could put the calculation logic in an Event task. Triggering the Event task with your user request.

robobob said:

you could put the calculation logic in an event task. Triggering the event task with your user request.

Click to expand...

+1

scarbroughm372 said:

when I attempt to even add one more output to the program, the system will lock up at some point.

Click to expand...

What causes the system to lock up? Does the watchdog timer timeout and trigger a fault?

Also, if the calculations are triggered by user request, then the Event Task is the way to go. That could still delay the continuous task if the event task runs at a higher priority, but again if triggered by user request, these calculations could probably be split across several scan cycles.

If it is a watchdog timeout, another solution is to increase the timeout value. If a small change is the difference between normal operation and a watchdog timeout, then that timeout value is too small to begin with.

Thanks for the suggestion of the event task.

As for the system locking up. that is the strangest part. There are not watchdog events being triggered. After my last message, I was starting to ponder the question of error logs. I was able to get a hold of another computer with the program and started looking. (The watchdog for the main task is 100 ms but the scan time is running ~20 ms). I could not find any red flags on the system. Another aspect of the machine is that it communicates with the drives over ethernet IP. Could that have something to do with this? I am worried about digging into that part of the system at this time while the machine is in operation.

Ah.


I think it might be a bit more important to know why the 1769-L36ERM locks up, before chasing possible solutions.


drbitboy, D.M.D.