SLC scan time problem?

[CeCo3]

Okie,


Thanks, the real magic is having an eight channel analyzer. The continuous recording capability gives you a real opportunity to study machine behaviors over time, even if it means millisecond by millisecond.

The SLC5/04 is lightly loaded, meaning there isn't a whole lot going on except measuring two inputs, calculating statistics, populating a data table and messaging the table to the main controller once per revolution. Yeah, I'm pleased it holds the 4msec pretty well, all things considered.

The encoder is an AMCI unit with an external relay board providing the timed interrupts. That makes it very accurate because the SLC does not generate its own timing strobes (we don't have an HSCE card). Darned if the manufacturer didn't route the precise timing strobe back through the SLC though, meaning the process is still somewhat scan dependent.

Yessir, ControlLogix would be the way to go.

Heck, we had a kickers that had AC solenoids driven by zero-crossing SSRs, so we would lose up to 8msec waiting for the solenoid to activate. These things also had short a duration cycle, and they couldn't figger out why the kickers were short stroking. Hmmm, we were only seeing three alternations of AC for the entire kicking cycle. Arrgh. I replaced dem solenoid-driven cylinders with double acting cylinder controlled by DC solenoid valves. Huge improvement.

Lots more stories with low hanging fruit.

Nice chatting with you.

CeCo3

 

[CeCo3]

Okie,

I'll see if I can find some recordings with the scan rate heartbeat signal included and post them.

CeCo3

 

[OkiePC]

Ahh...AMCI...is it a resolver interface with onboard transistor outputs?

We used a resolver card with onboard transisitor outputs controlled by the card very quickly (5ms repeatable response I think...) It was in a PLC5...very effective, just had to do well timed BTW instructions to change the output windows...

Our app with the hardwired outputs on the card was a corporate design and it depended on the AMCI card to operate SSRs directly with its transisitors so the PLC was blind as to the state of the final control element for the tire assembly drum.

Maybe that's why your team routed the signal back through the SLC...for feedback...signal proofing?

I love their products (AMCI).

We had great luck with their HT-20 resolver in high impact apps. Then, when we upgraded tire building machines to C-Logix, we used their C-net based unit...forget the name...nexus or something I think...

It could get up to 8192 ppr from the same indestructible resolvers we already had...very nice product line-up AMCI has...

Our problem with the corporate design was having to change the presets too often and too quickly. We were using two windows and two AMCI transistor->SSR outputs to stop an assembly drum at about 32 different positions in a 60 second tire building cycle.

It stopped the drum "in position" by toggling the state of a high speed clutch/brake coupled to a servo motor!

The motor was being used like a high dollar preset speed VFD...running constantly at one of four different speeds...positioning by disengaging a big air clutch, the positioning was terrible...plus or minus 30 minutes (15 degrees)!

They didn't even think about trying to get within a few degrees with that setup, the techs would adjust the window settings at the HMI based on a twleve hour clock +/- 1/2 hour!

I did away with the output hardwiring and closed the positon loop in the PLC to clean that machine up and improve positioning acuracy tremendously. I could get to within 5/1000 of a rev every time. (2 degrees) by ramping the ananog output to the servo amp as I approached the target. The increased smoothness let me increase the top speed to offset the cycle time lost due to ramping so overall product throughput was unchanged.

We couldn't afford a bunch of motion controllers to do it on all our other machines, but we had spare anallog outputs already...you know me...Mr "On the Cheap" and all...got rid of a bunch of wire and relays too...not many things make me happier than a dumpster full of relays and old wire, and a clean near-empty panel!

 

[Peter Nachtwey]

Thanks, the real magic is having an eight channel analyzer.

You have got to be the first. So many don't have a decent scope.

The continuous recording capability gives you a real opportunity to study machine behaviors over time, even if it means millisecond by millisecond.

That is nice. Now you fear no evil. Logic analyzers are very handy if you can set it up to trigger and save events that might happen every other day or week.

The SLC5/04 is lightly loaded, meaning there isn't a whole lot going on except measuring two inputs, calculating statistics, populating a data table and messaging the table to the main controller once per revolution. Yeah, I'm pleased it holds the 4msec pretty well, all things considered.

Here is where I agree with OkiePC. A real motion controller could do the PLC, encoder input and the logic analyzer functions. Not even a control logix could beat it.

Back on the indirec addressing topic. Indirect address can be much slower than direct addressing so it should be used wisely. If there is a UDT or structure that is going to be accessed many times using indirect address I would copy that data to a working area and access the data directly. This technique is also easier to debug because one can see what is happening in the working area much easier.

 

[OkiePC]

You have got to be the first. So many don't have a decent scope.

OKIE::CE, that's a high (and rare) compliment from a true guru

That is nice. Now you fear no evil. Logic analyzers are very handy if you can set it up to trigger and save events that might happen every other day or week.

OKIE:Okay, I am convinced. How much $$$ for an 8 channel Logic analyzer?

Here is where I agree with OkiePC.

OKIE:Thanks Peter! You see, some of us do pay attention and learn here...thanks for all your nuggets of truth...somebody should start a pinned link called "Golden Nuggets Of Truth in Controls" with some sort of committee based editorial rights dispensed to elected gurus like Peter, and too many others to list...

Gotta go finish my fence at hit the shower...hot date later...

 

[CeCo3]

Okie,

I'm with you on AMCI, great products and service. (We actually crossed paths on this once before...

• http://www.plctalk.net/qanda/showthread.php?t=30369).

Yes, we have an EasyPak SLC module, a resolver and a SSR relay board:

• http://www.amci.com/plc-modules/plcmodules-slc500-packaging-controllers.asp

The trigger pulse from the AMCI SSR is routed to a SLC input and performs two functions on our machine:

1) The entire "trigger" pulse is delivered through a SLC output to a "weighing instrument" (how's that for vague?) where it switches the instrument's output signal back and forth between free-running mode to peak-hold modes. The instrument output signal is then connected to an analog input on the SLC.

2) The trailing edge of the trigger pulse is used by the SLC to capture the voltage level present on the analog input.
​

No one, including myself, was aware of how sensitive this measurement system was to the small scan rate variations inherent to the SLC, even the machine manufacturer. But, armed with time and my l'il buddy DataQ, I was able to conduct some very interesting experiments. One of the most interesting revealed the SLC imposed a 10% accuracy measurement error simply because the trigger pulse, having to enter the SLC, picked up a varying delay. Ten percent error just because of the scan rate! Another discovery revealed "normal" mechanical impact of machine parts was causing the "weighing instrument" pickup to vibrate at its resonant frequency. This oscillation was very brief (1-2msec), but sufficient to get picked up as a false signal peak (remember, we capture at the end of peak-hold). This would have been very difficult to diagnose and isolate without the data analyzer. But, I digress. My whole point here was to explain that the manufacturer routed the trigger pulse through the SLC so the instrument analog signal could be left to free-run when calibration activities were occurring.

Okie, I am very impressed with the improvements you made to the tire machine. Wow, +/- 15 degrees? I have to chuckle about the techs. No different here. Give them something to adjust and they will. My motto when designing solutions, no slots and no pots!! Most of the time I can stick to it, but once and awhile I gotta give em a window or slot to accomadate variations elsewhere. I'm sure it felt great tossing the wires and relays in the trash.

After listening to you and Peter it seems I need to get some exposure to motion controllers. This isn't the first thread I've come across hearing about how beneficial they are.

I'll comment later about the DataQ analyzer.

• http://www.dataq.com/products/hardware/di730.htm

Gee, I hope PLC_Newbie can sort through all this. Kinda got off-topic.

CeCo3

 

[CeCo3]

Peter,

I used to be Mr. Oscope around here when I first arrived. Out of 20 technicians and engineers in the group, only three of use really used the scope, so your point is well-taken. I spent a dozen years in the military working on component-level avionics and it wasn't much different back then, some people used the scope quite well, some only when they had to and the rest not at all.

Working on machinery that has cycle times ranging from hundreds of microseconds to hours and days, it became quickly apparent that even our Tek 4-channel color scope wasn't going to cut it. My manager and I both took a chance and purchased the DataQ DI-730 analyzer and I've never looked back. I can (and have) record eight channels for hours or days. Again, this thread lists some of the many features:

http://www.plctalk.net/qanda/showthread.php?t=28807

Granted, many readers on this forum cannot afford the $4,300 price tag for the analyzer and software. DataQ does offer some other cool models with various features that might still be useful at a fraction of the cost. For those readers who do have deeper pockets, get one! Even better, they now have a model that can be daisy-chained together withup to eight other units across a dedicated ethernet line. Imagine having up to 64 channels of recording capability distributed across large distances (up to 100 yeards between nodes) AND all files SYNCHRONIZED!!

DataQ isn't the only vendor out there, but in my book they are very, very good and worth a look. No programming is required, truly plug-n-play.

Anyhow, Peter I appreciate the affirmation in your previous post. I hope someone listens to you.

I still need to dig up the file I promised Okie....

CeCo3

 

[timbo_uk]

Not been here for a while, but wow! That was an intersting read. Thanks

You guys seem spot on with your knowledge and programming skills!

 

[plcking]

Thanks for that, we are good here.