G3 Data Log failed to create new file

OkiePC

Lifetime Supporting Member
Join Date
Mar 2005
Location
ENE of Nowhere Oklahoma
Posts
11,762
I am using a Red Lion G306A as the HMI to an in motion check weigher scale for cases of sausage.

I must be able to log the weight of each case that crosses the scale. We process about 10,000 cases per day, from about 6 am to midnight. The machine sits idle at night and powered up.

The weights are retrieved from a sorting SLC along with barcode string, and robot infeed lane assignment.

At first, I had written my own code to log the values, but then I realized I was committing 10,000 write cycles per day to the CF card (Sandisk Ultra 2Gig), and wanted to try to take advantage of the built in logger which buffers writes and only commits them to the card every two minutes.

After working with JeremyH, I got the trigger logic, and file creation settings worked out and seemed to be doing okay, although once every two days or so, I get a garbage entry in my csv file. I think that might actually be junk coming from bad barcodes on the packaging, but I am not 100% sure.

Last Friday, the system stopped logging data about 10 pm, and didn't log any data over the weekend. Monday, when I saw this, I checked the CF card status using the function CompactFlashStatus(); which returns a value of 5 which means mounted and ready for use. I have a screen for CF functions, and have a button for that, and several other things.

So, I made a quick change to the file and sent an update to the HMI, and it started logging right away.

This morning, the same thing happened. Normally, when I come in, there is already a log file created at midnight, and it might have data in it if the previous shift runs past midnight, but other times when they finish before midnight, the file is there, but empty. Today, there was no file, so I waited until production started to ensure that my Triggered log should have executed, and still no log file was created.

So, I went (remote view) to my CF functions screen on the HMI and pushed a button that will execute a LogSave() command, and that caused the HMI to create the file and begin logging again.

I don't know if this is a Friday Night Glitch, or if I have a bad CF card (haven't tried my spare yet), or if this is simply a weakness in Crimson. One of the promary reasons I chose the G3 was this logging capability, after hearing of so many issues with the PV+, so I must figure out what is wrong, and make it work 100% even if that means going back to my custom logging routine.

The very last successful entry in yesterday's file has strange characters for the barcode string. Looking at the file in notepad++, there is "&" followed by an ESC character, then the expected lane assignment integer and a CR, LF.

I think its possible my barcode reader occasionally chokes and reads junk (not its fault, the barcodes aren't perfect), and perhaps that junk makes the HMI do the Heimlich too, and then refuse to eat any more.

I am confident we can resolve this...I sure don't want to go through the agony of switching platforms. If I could detect the problem it would be easy to deal with, but the function to check status return normal values, so I don't really know what to do next.

Has anyone else had similar issues with the data logger using Crimson 3.0?
 
This would be how I see it occuring.
You know as I know that at the end of shift room sanitising start before the last item reaches the end of the line, on fridays its always even earlier and they hose the bar code reader before the last box has passed it, or at least managed to fog up the lens.
If it doesn't move with water it doesnt move.

Just my thought, how about creating an end of day code within the your system that appears to be a valid bar code that will allow data log to close.
 
They don't wash down that room daily. It does get washed monthly I believe, but that is with everything powered down.

After doing some more research into the system, I think it might be possible for the sorting SLC to write to the registers that are being logged. I am not sure how much time it takes for the logging to occur, but I have added 0.2 seconds so that the logging will have more time to complete before the next item is queued up.

It might be a week before I know the results though! It's weird that both times the logging stopped, that it happened toward the end of the shift on Friday night.

There have been only a handful of times over the past week (maybe once every 5000 triggers) that I get bad data in the log. The first time my logging quit, the last entry was (I added the spaces for clarity):

Code:
2010/10/15,23:51:04,37.90,&,1

This was before I added the 3rd item to the log, so it shows the date, time, weight, and a valid barcode. This happened too early in the night to be the end of production. They always run til at least 11 pm, often they run a little past midnight.

Last night when it quit:

Code:
2010/10/15,  23:51:04,  37.90,  &,  1

There is a little square before the ampersand shows as an ESC character in Notepad++, but the forum keeps erasing it in my post...

It just happened to be a bad barcode read (or my SLC over wrote the data during the read of the ST element), but it still logged the lane assignment (1) at the end after the junk barcode data, so that tells me that the barcode reader did work, or it could not have sorted the case to Lane 1.

Yes, I am leaning toward the likelihood that my data is on rare occasions getting changed by the SLC while the G3 is trying to log it. I still think that the logger should keep working, even if it means starting a new file. On the 8th when it quit, it didn't log for two days, surely it should try to create a new file at midnight, even if the old file is fubar. If that's not possible, then there needs to be some way for me to know when the logger quits working.
 
Last edited:
paul what about having the barcode go directly to the G3 instead of the SLC? Do you have any Banner cameras around? I would use some type of visual capturing tool to see if the barcode is bad.
One shop I worked for I bought a DVR that would record on contact closure. A cheap camera from ebay and under a 1000 we had a ready made visual logger for bad data. I used it over and over until someone else needed it at home I guess.
 
The Barcode reader has been very reliable, A camera would see an ink blob the same way, and I really don't think that is the issue. The good read rate of the existing reader is about 99.95% I am not breaking the cardinal rule of maintenance by fixing it.

Garbage in a string shouldn't break the logger anyway. And, it usually doesn't. I think I am going to stick the new CF card in the thing in the a.m. and just wait. I am sure the Red Lion guys will see this thread and help me with a solution. They have not let me down so far.

Our IT dept. still hasn't given me a location for all this data to be logged anyway, so I still don't have the FTP services turned on. In other words, they won't miss the data that is already there on the existing card (or the stuff that got missed last weekend and this morning), but once the Production Gods get ahold of all this new information, they will expect it to be bulletproof.
 
Last edited:
Yea 99+% of reliability works for me. You are right the bad data SHOULD NOT cause a crash.
How does the SLC respond to a bad data senerio (I can spell)? Does that code stumble on itself if you toss in 1 bad read? I have seen several rough implementations of ASCII in SLC. I am sure you have too.

You know I am just tossing out ideas that are probably not the answer. JeremyH and DanY will probably say yea just do this and that.
 
Yea 99+% of reliability works for me. You are right the bad data SHOULD NOT cause a crash.
How does the SLC respond to a bad data senerio (I can spell)? Does that code stumble on itself if you toss in 1 bad read? I have seen several rough implementations of ASCII in SLC. I am sure you have too.

You know I am just tossing out ideas that are probably not the answer. JeremyH and DanY will probably say yea just do this and that.

The reader is on Devicenet. If it sends a bad read to the registers in the SLC (that get converted from N to ST files) the SLC will not find a match and the cases get rejected (lane assignment =-1). No serial hassles in this app.

When I am seeing bad data in the log, and next to it there's a good lane assignment, that tells me that the value was a good match for one of the lanes when the data was examined in the SLC.

The corruption must be occurring because:
a) After the lane assignment has been made, the SLC overwrites the good data at the same time the G3 is reading it for the log.
b) There's something imperfect going on in the G3.
c) There's some temporary or location-specific problem with the cf card.

I can't think of anything else.

Looking at more data, I found one on the 13th where the logger triggered before shift started at 4:30:08 am and again at 4:52:44am and put a value of 0 for weight, blank for barcode and 12336 in the lane assignment. That value can only be -1 (no lane assignment, reject) 1, 2, 3, or 4 (4=rejected based on gross weight). The only way it could log at all would be if the system was running (they stop the belts at night), and three successive photocells were blocked to increment a SLC counter, which is a remote possibility, but no way can that lane address ever contain 12336 even if SLC is writing a -1, I don't see any way the G3 could interpret the bit pattern for 12336.

Perhaps the week long issue with static which was causing my scale module to internally reset damaged the cf card or the G3?

The PLC never has hiccupped though, so I dunno...new card tomorrow and let it ride until/if it happens again.
 
OK I was just throwing out WAGis there a wayto have the G3 only update on a trigger from the SLC? that may limit the reading and writing to the same address at he same time.

I didn't finish reading theat thread about static. I will shortly.

I know what it was. The G3 got lonely knowing that you would be away all weekend and wanted to see you. I am sure you have bee spending qaulity time on this system lately.
 
JeffKiper said:
OK I was just throwing out WAG

I do appreciate your input, Jeff!

JeffKiper said:
is there a wayto have the G3 only update on a trigger from the SLC? that may limit the reading and writing to the same address at he same time.

The way my trigger works right now (I may change it), the SLC that sorts the cases increments an integer (Case_Counts). The G3 monitors that tag and has an event based on increase in value that sets an internal flag tag=1 (Log_Trigger).

Log_Trigger is the trigger for the data log.

It also has a trigger action (active on) to do two things after a 500ms delay:
1) It assigns the value of Case_Count to Case_Count_Old
2) It resets itself back to zero

The SLC tag Case_Count_Old is used by the SLC to know when the logging is done, so that it can move the next times into the tags that are being logged. It isn't the cleanest way of doing things, but due to the physical location of the scale and barcode reader, it was the best way to get the right information correlated and into the G3. The main purpose of the G3 is for an interface to the Scale.

I have considered changing the trigger logic such that the SLC simply sets and resets a bit to cause the log to occur, and I may just do that in the morning as a test.

Last Friday, when the logging stopped, I looked at the state of the internal tag Log_Trigger (using Crimson 3.0's handy dandy watch window) and it waqs still set. It failed to turn itself off. This would explain why the logging stopped. I was working with JeremyH via email and he was also puzzled by some of the data corruption. I asked him whether the event "Active On" is a one shot type of action or would repeat if the tag was still on, but he hasn't replied to that question yet.

This morning, I forgot to look at the state of that trigger tag, but the symptoms are a little different in that the G3 never even created a new file at midnight.

JeffKiper said:
I didn't finish reading theat thread about static. I will shortly.

It was pretty long winded. I tend to put in too much info, sometimes forgetting the important stuff.

The root cause ended up being wash down bearings on a conveyor with a rubber belt mounted generating static. Yep, those composite non-conductive housings were keeping the static in the coveyor rollers from discharging. I still have rigged pieces of wire to keep the static out of it, but I will try to get them changed to stainless housing bearings as a long term fix.

JeffKiper said:
I know what it was. The G3 got lonely knowing that you would be away all weekend and wanted to see you. I am sure you have bee spending qaulity time on this system lately.

I think the weigh scale is cursed. It used to be located in the packing room where they wash it every night, and it has always been lots of trouble, even with the original control system.

When we moved it to a more dry area and got rid of the original controls, we gained a lot of functionality, but the gremlins refuse leave!
 
Okay, today, I changed my log trigger so that it is a SLC tag that cannot get stuck on. Now I am more dependent on comms working. If I lose comms for more than 3 to 5 seconds, I could miss a log entry. For two weeks I have had no comms issues, so it is not a major concern, just something I planned for.

I originally constructed the logic to tolerate slow comms or a comms loss of up to 50 cases (about 3-5 seconds between cases worst case). I did this because the SLC is connected to our LAN via a NET-ENI module. So I had the SLC increment a counter and move the next items into the the log addresses, wait for the G3 to match the counter value and move to the next...

I made room in the data tables today to be able to reconstruct that method for up to 100 cases, but it is probably overkill. I didn't finish writing the PLC logic to rotate the queue yet. In the three weeks since I put the system in, there have not been any comms losses, and the connections are through a very reliable Hirschmann switch.

So, I think my question for the Red Lion gurus is boiled down to this:

If the trigger tag for a Datalog (Triggered Snapshot) gets "stuck on", can that prevent the logger from creating a new file at the specified interval?

Paul
 
Could you use a combination trigger? Use the triiger from the PLC and some part of the G3 internal clock? That would keep this from being on constantly. Just a guess. If the trigger was on it would be toggled by the clock pulse. Would that make it log twice or overwrite some other data.

Again SWAG
 
The log trigger is and Edge event so if it stays on it won't keep logging. Also if your trigger bit gets stuck on and its time to create a new file (after midnight) a new file won't be created until the trigger goes low and high again.

Thanks
Jeremy
 
Thanks, Jeremy.

That appears to have been the problem. I had the trigger as an internal tag, and it was supposed to turn itself off after a 500ms delay, but twice it failed to successfully do that. The tag was turned on, by a trigger (rise in value from the case count tag). It's conceivable that was occuring at the exact timing to turn it right back on.

Regardless, it was easy to change the source of the trigger tag to a bit in the SLC, and add a line of code in the SLC to actuate it.

This has been my only significant issue with the G3, but now that I understand why the new log was not created, my confidence is restored.

The perfomance of the unit has been outstanding. I love being able to use remote view, and be able to make changes and restart the system in seconds without disrupting production. I can retrieve my logs in seconds from a browser, and I have really just begun to tap into the features. The scatter graph feature has been extremely useful in this application as well.

Thanks for the response,
Paul

By the way, I would like to suggest you add this sentence to the manual:
JeremyH said:
...Also if your trigger [logic stays] on and it's time to create a new file...a new file won't be created until the trigger goes low and high again.
 
Last edited:
Sorry for the late response, yes, changing my trigger logic solved this problem. I have not had any more issues with my data logs, and now they're being FTP'd to a central server so the bean counters can see the gross weight of every individual case of sausage we produce, the barcode string, what sort line received it, and the time it was logged.
 

Similar Topics

We are using RED LION HMI Since las 15 years. To day we have found that My log file has data up to 22 Mar 2024 1:16. Then After new Log File is...
Replies
22
Views
842
Hi , i currently have data logs running but i need a way to link a tag to them so if there ever not running i can trigger an alarm? what is the...
Replies
4
Views
1,803
Hi all, I am working on a project in Tia Portal v17, and I have a function block that is responsible for data logging. This data log begins once...
Replies
4
Views
1,755
I am stuck on something, and would appreciate if someone might have a suggestion to help me. I need to automatically email CSV log data from...
Replies
2
Views
1,736
Hi; I have installed Weintek HMIs at different machines. I have configured data logging and HMI logs the data in a file having extension...
Replies
0
Views
1,275
Back
Top Bottom