Data Table & .UDT SD storage limit curious thing.

[Ausman]

Hi all, I'm putting this in the main Vision forum, with a link in the SD card Suite forum as well.

Quite by accident I have found something curious going on with Data Table writes of UDTs. 

Late Sept last year I'd forgotten to do monthly downloads of daily logs at one site, and was sure that they would have gone over the limit and the recent ones would be missing.  In the main DT folder it was as expected, but the secondary log that I was sending to DT1 was 80 udts.  Read them all and cleared things out ready for the next lot.

I was bit puzzled by this, so I have been deliberately observing things a little more closely since on a system that the logs are only there for my purposes, which I've been tracking manually on and off.

Today I looked again, and sure enough it is all very curious. I quote from the Help file:

.udt - The Ladder function DT to SD creates .udt files and saves them in this folder, or in one of four sub-folders. Note that the main DT folder and subfolders DT1, DT2, DT3, DT4 can each contain 64 files, for a total of 320 .udt files.

On logging in with SD Card explorer, it looked like all the logging had stopped once the 64 limit was reached, with a little over 2 months worth showing in both DT and DT1.  I read them all, doing my normal process of check they have arrived in the PC OK, and then deleting all but the last few dates.  As usual I did the ones in DT first, then the ones in DT1.  At the end of this process I had some sort of error displayed after the DT1 deletion, which I didn't exactly take note of.....bummer.  I did a refresh of the view hoping it would clear the error and suddenly DT1 had more displayed right up to today's date.  DT didn't.  All the ones in DT1 were correct logs.  So DT1 had way more than 64 UDTs, being almost 4 months worth of daily log.

So it would seem that the 64 limit perhaps doesn't apply to DT1 and likely to 2, 3 & 4 as well.  The other funny thing is that SD explorer couldn't/wouldn't display all the logs that existed on the card.  But it did do so on DT1 after I'd deleted the earlier date ones.   So maybe it's a double issue type thing, where both the PLC and SD explorer don't like numbers bigger than 64, but some things still happen ok even though they supposedly shouldn't.

I don't currently have time or stuff on hand to fully explore this with a working mockup to test things.  But perhaps someone else does.  It mightn't work on a much quicker UDT cycle time, might only be a daily type thing....who knows.

But there is definitely something odd going on.   🤔

cheers, Aus

 

[Fernando Castro]

On 1/12/2022 at 7:53 PM, Ausman said:

Hi all, I'm putting this in the main Vision forum, with a link in the SD card Suite forum as well.

Quite by accident I have found something curious going on with Data Table writes of UDTs. 

Late Sept last year I'd forgotten to do monthly downloads of daily logs at one site, and was sure that they would have gone over the limit and the recent ones would be missing.  In the main DT folder it was as expected, but the secondary log that I was sending to DT1 was 80 udts.  Read them all and cleared things out ready for the next lot.

I was bit puzzled by this, so I have been deliberately observing things a little more closely since on a system that the logs are only there for my purposes, which I've been tracking manually on and off.

Today I looked again, and sure enough it is all very curious. I quote from the Help file:

.udt - The Ladder function DT to SD creates .udt files and saves them in this folder, or in one of four sub-folders. Note that the main DT folder and subfolders DT1, DT2, DT3, DT4 can each contain 64 files, for a total of 320 .udt files.

On logging in with SD Card explorer, it looked like all the logging had stopped once the 64 limit was reached, with a little over 2 months worth showing in both DT and DT1.  I read them all, doing my normal process of check they have arrived in the PC OK, and then deleting all but the last few dates.  As usual I did the ones in DT first, then the ones in DT1.  At the end of this process I had some sort of error displayed after the DT1 deletion, which I didn't exactly take note of.....bummer.  I did a refresh of the view hoping it would clear the error and suddenly DT1 had more displayed right up to today's date.  DT didn't.  All the ones in DT1 were correct logs.  So DT1 had way more than 64 UDTs, being almost 4 months worth of daily log.

So it would seem that the 64 limit perhaps doesn't apply to DT1 and likely to 2, 3 & 4 as well.  The other funny thing is that SD explorer couldn't/wouldn't display all the logs that existed on the card.  But it did do so on DT1 after I'd deleted the earlier date ones.   So maybe it's a double issue type thing, where both the PLC and SD explorer don't like numbers bigger than 64, but some things still happen ok even though they supposedly shouldn't.

I don't currently have time or stuff on hand to fully explore this with a working mockup to test things.  But perhaps someone else does.  It mightn't work on a much quicker UDT cycle time, might only be a daily type thing....who knows.

But there is definitely something odd going on.   🤔

cheers, Aus

 

I know what are you saying, same happened to me, seems that the PLC can in fact store more than 64 files, but only can handle 64 allocated on the SD card, I am not sure what is the limit and where are allocated, but if you store more than 64 an then delete some of them, the other files starts to appear... 

[Ausman]

After simply letting things run their normal daily course on the logging I'm doing, I can confirm that DT1 (at least) seems to handle more than 64 udts.  I don't know how many more, though.  My previous comments, and backed up by Fernando's observations as well, is that upon deleting files from the folder using Card Explorer, remaining ones appear upon refresh.

For interest's sake I am going to change a few things in this logging so that the writes are being done to DT1-4.

As a minor aside, in again looking at these logs where I derive the name from the RTC To ASCII function , I still remain slightly annoyed at how I can't easily get YY_MM_DD in doing so.  During a variety of sorting on the PC, the usual system of naming conventions can interrupt the logical sequence if using a name sort.  ie 14_01_22  (using Aussie date convention) is then followed by 14_02_22 etc instead of 15_01_22.  The solution I always use to get around this issue is that anything with dates in the name is done with the year first, then month then day, but this option is not available innately and needs some minor data fiddling to get it.  Apart from my data rearranging method for the name source MI, does anyone know if it is easily added to the list in the function itself?  I don't think it could be as I reckon it would be firmware related, but perhaps it is easily done.

cheers, Aus