Red lion dspsx000 cf datalogging

[thelectric]

Having touble with random missing data in datalogging to csv file on cf card onboard red lion data storage plus dspsx000.
Data is visibly present in plc registers for the dspsx to read. Communication appears to be good.
Using red lion crimson3.
Anyone have any ideas where my problem may be?

 

[Ken Roach]

Interesting.

I think the big question is "Does Crimson 3 place a zero in the field when it gets a communication error for a data register" ?

Since its an SLC-5/05, there isn't likely to be a synchronicity issue with ladder logic and communications. SLC-500 controllers respond to communication requests during the housekeeping portion of the scan, not during ladder routine execution like ControlLogix do.

This being an SLC also means that you have a better chance of analyzing the data traffic using Wireshark.

 

[OkiePC]

What writes to your internal trigger tags? I see no usage that indicates how they change states.

The only time I have had issues with the logger in Crimson was when I was not properly changing the state of my trigger bits.

This answer from JeremyH helped me solve my issue:
http://www.plctalk.net/qanda/showpost.php?p=396030&postcount=12

 

[thelectric]

Thanks for the reply Ken. I had been pursuing the communications issue with Red Lion Tech support. Their advice was to place the the IsDeviceActive() in my Data Log Contents to record whether communcation was there during the log. The records always show it is. So either that is a minor check, or the problem lies elsewhere.
I had been questioning whether the data was being lost in the buffer between sampling and the two minute write to the CF card.
This system worked flawlessly for 5months with the single Mixer1 log running. The problems appeared after I added the second Mixer2 log last month, doubling the amount of tags being scanned. On the SLC side, the log triggers are prevented from happening simultaneously.

 

[thelectric]

Thanks for the reply OkiePC. The internal trigger tag is placed high by the program() after it completes its scan. The external trigger calls the program().
This logic was recently added by the Red Lion tech support to clean up the characters in my strings. Prior to this, I ran the logging directly off the external trigger, with the same missing data problems as I continue to see.
I will review your link.
As well Ken, I will look into the WireShark.

 

[OkiePC]

Thanks for the reply OkiePC. The internal trigger tag is placed high by the program() after it completes its scan.

Okay, I see now. I should have opened the search results when I looked at usage.

So the external tag goes true, which calls Program1. Program1 Trims some string tags, and then sets the internal bit for the data log trigger.

However, the same external tag has an "off active" trigger which will turn the log trigger right back off.

Ideally, you would want the trigger tag to stay true until it is certain that the logging took place. This might mean that you have the SLC set the bit (think OTL), and let the Crimson device reset it so that there is a handshake (without adding more tags). Then the SLC could "know" whether logging took place by examining that bit for an off condition. You could go even further with that approach and set up a queue in the SLC to ensure that if comms are squirrely, no data gets lost...at least to a reasonable degree.

Reading how it worked great before you doubled the tags, it sounds like the added tags may have slowed down comms a bit. So before the tags were added, perhaps the external trigger was true (as seen by the Crimson device) for a much longer period than is the case now, since the increased load may have introduced more lag time.

As a quick fix, it might help to add a delay to the "off active" trigger which turns the log trigger bit off. There is a value in ms for all of these events which you can adjust.

How frequent are these log events taking place in the worst case scenario? I mean, what is the minimum time between logging events?

Also, I don't think it matters if you trigger two logs at the same time. I have a different system in which I have 8 logs going on all with unique triggers that are not at all interlocked. There are only four or five tags per log, but they are reading from a SLC 5/03 via a DigiOne IAP on CH0 at 19.2k through 4 ethernet switch hops! It has been solid as a rock too, as far as the logs are concerned. I may be wrong, so if the experts at Red Lion suggest interlocking the triggers, listen to them, not me!

Paul

 

[Clay B.]

I agree with Okie. To keep things simple I would have the SLC set the Data Log trigger and reset the trigger. By doing this you will know the PLC went thru at least 1 scan when the data logging started and 1 scan when it stopped.

As a general rule I prefer whatever I am reading data from to trigger my logs.

I have also created multiple logs and did not interlock the triggers. With the time you have between triggers I really can not see this as a problem. The G3 only writes to the Compact Flash every 2 minutes and I know from my work with it. It can store a rather large amount of data.

What puzzles me is the fact you are getting zeros. I would figure if it was a trigger issue you would get old data not zeros. The zeros would have to be written by the PLC not the data log.

FYI... That trim program is slick... Is that Jermey's handywork?

 

[JeremyH]

Clay,

I can't take credit for that program

thelectric,

Can you email me the original log file? [email protected]

 

[thelectric]

As I understood it from Red Lion support, all tags are continuously scanned. The sample of the tags is intiated on the rising edge of the trigger, and placed in the buffer for the next 2 minute write to the CF card. Therefore I have assumed that the duration of the trigger has no effect. I have in the SLC logic been using a OTL with a 3sec TON to fire the OTU. (There is no handshaking.) Because the SLC communicates with the HMI's via same socket, I figured we needed a time period for the DSPSX & HMI's to take their turns communicating. In experimenting with the time duration a week ago, it was observed that dcreasing to 1 sec begns to entirely miss logs. Increasing above 3sec begins to increase the amount of missing values.
I will experiment with delaying the interlock reset of the internal trigger and maybe handshaking as well today when I arrive back onsite.
Yes the PLC clears the register 10sec after the trigger goes low, before the next batch's values begin coming into the register. We know from other experimental parallel data logging that the missing data is present for the DSPSX to read.
I believe is was Norm that deserves the credit for the trim program.
Thanks guys for your input.
Jeremy, I have sent you an email.

 

[Clay B.]

As I understood it from Red Lion support, all tags are continuously scanned.

Kind of... Tags are read as they are required... Simple way to test this is to create a display screen that has a Tag NOT defined in your PLC plus a few that are. Then create another page that has all Tag defined in your PLC. You will notice a difference in update rate when your on each page. The page with the undefined tag will run real slow or stop all together. So you read tags continuously only when needed by the G3

The sample of the tags is intiated on the rising edge of the trigger, and placed in the buffer for the next 2 minute write to the CF card.

Correct the CF card is only written to every 2 minutes. Basically you log resides in the RAM of the HMI and is transferred every 2 minutes. With the times stamps I saw on your logs you will have one sample per write to CF since your sample rate is over 2 minutes

Therefore I have assumed that the duration of the trigger has no effect. I have in the SLC logic been using a OTL with a 3sec TON to fire the OTU. (There is no handshaking.) Because the SLC communicates with the HMI's via same socket, I figured we needed a time period for the DSPSX & HMI's to take their turns communicating. In experimenting with the time duration a week ago, it was observed that dcreasing to 1 sec begns to entirely miss logs.

Kind of lost here. How did you confirm you were missing logs?

Increasing above 3sec begins to increase the amount of missing values.
I will experiment with delaying the interlock reset of the internal trigger and maybe handshaking as well today when I arrive back onsite.

One little trick I use to make sure I have the latest data is to look at the PLC clock. I look for a change in value as part of my trigger so I know I have a confirmed read before I log the data.

Yes the PLC clears the register 10sec after the trigger goes low, before the next batch's values begin coming into the register. We know from other experimental parallel data logging that the missing data is present for the DSPSX to read.

10 seconds is a boat load of time for something like this unless you have some seriously hosed comms. Is the HMI and DSPSX looking at the exact same data points in the PLC. If they are I would create a separate register in the PLC if I have room. If not I would use Gateway blocks to send the data from either the HMI to Data Station or vice versa. I try to avoid having 2 devices access the same data unless I know for sure it will be at separate times.

I believe is was Norm that deserves the credit for the trim program.

Awesome program Norm. I am going to "borrow" it from you. When I looked at it, it reminded me of some stuff Jeremy had written for me so I figured it was his handy work.