CompactLogix using Analog Press Encoder

That part has a 5000 Hz sample rate - looks ok for a RPI of 5ms


jrupp82 - have you used the trend functionality of RS logix 5000 ?

Set up a trend with angle, your timer and the trigger - watch what is happening - you should be able to see each 5 ms RPI step change , see how big each step is and when you are triggering SHOE analysis of the trend will assist you in working out what is happening

I have not opened your program yet but there are some timing things that may be needed / help

1) copy your angle into a local variable and use the local variable for testing - the value can change mid instruction
2) You are triggering an Event that then calls your SHOE TASK - why?
Have you thought about using a task that is attached to the RPI of the analog being updated - must be a very fast (ie small) bit of code
3) Change your "in window" logic - Think about using a wider window and when you exit that window test if you are on the trigger side of the wider window - if so then eject - you may need to set a latch if reverse is a possibility
The window logic is saying "have I just passed 130 deg in the forward direction" if so then run the "SHOE" task
4) what priority is the "SHOE" task (maybe I should just read the program but I am tired)
5) You may need to cause the output to turn on before it is required as you speed up (reaction time of the solenoids)

MichaelG said:

That part has a 5000 Hz sample rate - looks ok for a RPI of 5ms


jrupp82 - have you used the trend functionality of RS logix 5000 ?

Click to expand...

No I hadn't used it before. I used this tool to finally see what was going on. I had been looking for this within RSLogix, but I'm new to the software, and I was looking for a tool that would be called "scope" or "oscilloscope", something to that effect. I worked exactly as I was looking for to help me get to the bottom of it all.

I had received some advice from another forum to increase the Analog Input card filter to 500Hz. While this made me susceptible to noise, it would increase the read time. It seemed to do the trick. Because after changing to this value, in conjunction with use of the Trend tool, I was able to identify a mechanical glitch I had in the part not releasing from the press tooling cleanly. The humidity had been crazy in our plant for the week, and this was causing the clay to be "sticky". The parts weren't always coming off clean and to the naked eye, made it appear like a late fire issue. I definitely did have an issue when I started, but it looks like I had multiple things.

In answer to some of your other questions:

MichaelG said:

2) You are triggering an Event that then calls your SHOE TASK - why?
Have you thought about using a task that is attached to the RPI of the analog being updated - must be a very fast (ie small) bit of code

Click to expand...

I'm not sure I totally follow what you mean here. Are you referring to using a periodic task with the same RPI as the Analog card? The reason I chose an Event Task, was from my reading I read it would take priority of everything else when triggered. Because I was trying to nail down an issue that I thought was being trumped by other programs/tasks, I chose the Task type that would trump all others. As a result, I think I may be interfering with some of the other tasks being ran in the program.

MichaelG said:

3) Change your "in window" logic - Think about using a wider window and when you exit that window test if you are on the trigger side of the wider window - if so then eject - you may need to set a latch if reverse is a possibility
The window logic is saying "have I just passed 130 deg in the forward direction" if so then run the "SHOE" task

Click to expand...

Not sure what you mean by this either, but if I make my window wider, wouldn't that provide more possible variation for the trigger to happen in? I was hoping to come up with a solution where I could narrow that window to create a trigger that was more of a pinpoint that such a broad brush stroke.

Anyhow, to elaborate on something I said above, I think that I may have some added issues in lag of other machine features as a result of changing task priorities, RPI's, etc. I feel like I put a lot of "guessing" into how to set that up, and I wandered if anyone could provide me with a little bit of protocol for choosing Task types, priorities and RPI's for them?

jrupp82 said:

The parts weren't always coming off clean and to the naked eye, made it appear like a late fire issue. I definitely did have an issue when I started, but it looks like I had multiple things.

Click to expand...

I use an iPhone and the free app CoachMyVideo and I get about 3 frames per 100ms - that I can step through forward and back frame by frame
There are other tools that do similar stuff

jrupp82 said:

Not sure what you mean by this either, but if I make my window wider, wouldn't that provide more possible variation for the trigger to happen in? I was hoping to come up with a solution where I could narrow that window to create a trigger that was more of a pinpoint that such a broad brush stroke.

Click to expand...

What you are trying to do is to trigger a ONE off action that occurs when the angle gets to a certain degree - have you looked at the ONS instruction?
Try some test code to see the difference between ONS and continuous
In the Code below MYDint1 will increment by more than 1 per revolution of RawAngle and the faster the angle is changing the less the count
However MyDint2 will only increment by one each revolution - independent of the speed

There is more coding needed to make it robust because if you are running backwards then MyDint2 will increment when the angle is 359.9 or less Deg

jrupp82 said:

The reason I chose an Event Task, was from my reading I read it would take priority of everything else when triggered.

Click to expand...

jrupp82 said:

Anyhow, to elaborate on something I said above, I think that I may have some added issues in lag of other machine features as a result of changing task priorities, RPI's, etc. I feel like I put a lot of "guessing" into how to set that up, and I wandered if anyone could provide me with a little bit of protocol for choosing Task types, priorities and RPI's for them?

Click to expand...

for a start read http://literature.rockwellautomation.com/idc/groups/literature/documents/wp/logix-wp003_-en-p.pdf
and
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm094_-en-p.pdf

Generally it is easier to control what is happening with minimum number of tasks
Easiest is all code into a continuous task - downside timing issues are PID (control loops) loops are free running and stuff that has to be checked often can be late

Then designers create say a 100 ms task for analogs and PID (usually slowly changing temperatures or levels) and say a 10ms Task for all of the quicker stuff

Other applications require high communications so they place the general code in a 20 to 40 ms low priority task (no continuous task) so the processor has a high idle time for the communications

For Motion rockwell has added a task to your processor that is hidden it has a fixed priority and misconfiguration can affect the motion planner and motion movement.

Have you looked into the MAR and MAOC commands - these commands allow you to have outputs turn on based on the axis position (angle)

A Tip: configure a virtual Axis to test your code on