Sequence of Event

[wsy_nte 0]

Hi... I want to create sequence of event logic using SLC-5/04 and wonderware. I want to record 10 analog inputs and 15 digital inputs. What kind of instruction that suitable to implement it? Any idea? How fast the slc can record the even (>100 ms)? Thank you for any suggestion. James

[Wordman 0]

you have a two learning curves to cross. 1- programming a SLC; 2- developing in wonderware Instructions? you could scale your analog inputs in the PLC with a SCP or CPT (see the AB Analog Input Module manual for programing examples). The SLC does not record the historical data, wonderware does. Speed? You can trend your tags at a 100ms (or 0 if you want) interval, but it will only record as fast as the driver polls the data, and assuming you are using a DH+ network I dont' think you will get that high of resolution.

[panic mode 246]

only for fast events you would have to record it in plc. this requires some plc code like use of indirect or indexed addressing (easy part) but the limitation is available memory (plc memory is quite small, not meant for this).

[paulengr 44]

Wonderware will poll the PLC. That puts something of a limit on the "resolution". For events that are faster than the poll rate from the HMI, you have to queue and handle events on the PLC side. These things are no fun to write at all. When I need to do this, I write them like this: 1. Create a circular buffer in memory. That is, you have an array of data with two index registers into the data. Let's call one "head" and the other "tail". Whenever you add to the data, you increment the "head". Whenever you remove data from the buffer, you increment "tail". If head=tail, then the buffer is empty. Whenever the physical index values overrun the buffer, you reset them back to the beginning. So if for instance you are using N10 as your circular buffer and it has 200 words in it (0-199), if head or tail equals 200, clear it (reset it to zero). Note: Why use circular buffers instead of FIFO's? Simple. The way that AB implements FIFO's is that they actually physically COPY all the words in a FIFO queue every time you unload an event, which tends to be slow. A circular buffer never has to actually physically move data around, although it takes more code to implement one. 2. Now, insert events into your circular buffer. You can just number your events or you can have an event number and a payload (data), your choice. The circular buffer really doesn't care. Insert events using the "head" index number. An example of an appropriate payload is if you store the PLC's on board clock (which has a fairly high resolution on a SLC) as a payload. Then you can retrieve not only the order of events but also very precise event timing. 3. Now you need to pass data to the HMI. Create another register called "handshake". The PLC itself never actually updates handshake...that comes from the HMI. The HMI should have a register called "lasttail". If "lasttail" and "tail" equal each other, do nothing. Otherwise, the HMI should read the event and then write the value of "tail" to the handshake register and "lasttail". Your "tail moving" code on the PLC should do the following: a. If handshake <> tail, do nothing (waiting for the HMI to read the new data). b. If handshake = tail, then check if tail=head. If so, do nothing. c. If handhskae = tail and tail<>head, then copy the next event into the outgoing event storage for the HMI and increment tail accordingly. This allows the PLC to read and store events, limited only by the scan rate of the PLC. Meanwhile, the HMI can read the events one at a time from the PLC until it has caught up. In general though very few programs I've written that use an HMI as a data logger operate with this kind of resolution on event timing. There are only 2 cases where I have used this sort of code. The first case is when you get one of those annoying "glitch" type events that happen so fast that the HMI never manages to capture what's going on. I had a 35 MBTU/hour oven inexplicably shutting off every couple days because of an input bit that would occasionally trigger for <20 ms. The second case is when I'm running a large production tracking program that keeps track of where everything is at on the production line, (several hundred units at once). This involves multiple PLC's. In this case the events themselves ("unit passed by") may be very fast but the average number of events per minute is relatively small. Some of the events require SQL calls. The easiest way to write this monster was to code the whole thing on the HMI and use event queues on each PLC along with clock synchronization to make sure that the events and the order of events is preserved.

[wsy_nte 0]

Thank you for reply. I used SLC-5/04 specially to monitor the events , no other application at all. I connect to wonderware using KTX card (DH+). How to record the time stamp of event? in PLC or HMI? Currently I write the code may using FIFO instruction. Regards, James

[BobLfoot 302]

If you record the timestamp in plc you'll need at least 2 integers {Hour, Minute} or max of six {Year, Day, Month, Hour, Minute, Second}. The HMI should be able to store the timestamp in one Date Variable. Much simpler.

[rpraveenkum 5]

Wait for some more time rockwell lanching alarm loging in the PLC itself with date & time stamping & retrive later http://www.plctalk.net/qanda/showthread.ph...ght=RSLogix5000