Sampler not works properly...

[ORSO2001]

Dear All,

I am finalizing my project and now I am testing if all works properly; at the moment I have 2 issue...one is reported in another topic (problem with HMI object) the second issue, but that is multi points, that I am having is with the sampler.

- I have 10 sampler, each with two feeds; in each sampker struct I have set as "start value" 1 for the .CSV file but when I switch from 1 to 0 the BIT about start/stop sampler the .CSV file is not created.

- when I try to save the sample file I pass to the struct its file name...that will be the name of the device and the date time; at the end the String will be length 24 characters; I saw that the struct take the String but the file tha was created don't has this name but still have the name automatically passed by the PLC (as the String name is not present)

- I don't know why but sometimes the file is not saved...also if the folder is empty...why?

to be clear the "save" cmmand is managed by checking the RTC.dayMonth...when this is not equal about a tag that I insert I will active a BIT that will put in "off" the record of the sampler...this for all sampler...at the beginning of each ladder row for each of this command I insert the "controll" of the SD status (busy).

I am using 1.23.25

[ORSO2001]

dear All,

ok...I understood the cause of this issue but I don't found a solution; at the end the procedure that I am using to reset and set the BIT start/stop sample, let me say, don't stay at "0" enough time to enable the file close and record in the SD...if I force manually the BIT at 0 , and let it 0 enough time, all works.

I have add a check about the "isSDbusy"; a check about the record status of the sample struc (that can be 0 if all is good or a negative value for error...I don't see a  value for "progress")...but all these don't works...what I can do?

regards

[Ausman]

Hi Orso, I'm not really into Unilogic but to me this sounds like some sort of buffer issue.  I would be adding an adjustable count system into your controls so that you can fine tune "X" number of scans occurring between your controlling bits changing to your desired states, including the system bits that say things have occurred.  The count would be set up so that it increments +1 every scan and you then do compares to trigger things after, for example, 20 scans have elapsed where your count would be up to 20.  In effect you would be making a simple variable timer for your commands that you can easily vary until you find the optimum point for every bit involved.  Upon the count being reached for each one it resets to 0, waiting for the next trigger.

cheers,

Aus

[ORSO2001]

hi Ausman,

thanks for the answer...if I well understood you are suggesting to add, for every sampler, a time counter to let the enough time, after every BIT reset, to close and safe the file!?

ok...I can try.

[Ausman]

Essentially yes.  As this is not a definite answer and is a bit involved to write, I would trial the concept on only a few to start with.  The aim is to give the system a little breathing space between actions.  But I would start at quite a high count to start with, maybe even 1000, and work backwards from there.  Here's hoping it works....fingers crossed.

cheers,

Aus

[ORSO2001]

ok...I will try and I let you know...anyway ...seems strange that , as for the DT functions, is not present a value, in the "Sampler.Status" to highlight "record in progress" or that the "SD Files.Save DT Busy" is not blocking the next action...

[ORSO2001]

ok...I tried with a PLC cycles counter of 1000, for each Samples.Start/End_Sampling...and works (also .CSV file is created)...I reduced until 2 cycles (very fast action) and also works...then seems exactly a buffer problem when 1 cycle is not enough to reach the "save file" command.

[Ausman]

That's great Orso. 

Given that it is only one cycle, I'm now wondering whether it might be a simple case of rearranging some of your program?  I have often fallen into the trap of having an action not operate as expected due to an incorrect sequence, and a simple rearrange cures the issue.

cheers,

Aus

[pascal]

I had the same problem, stopping the sampler, and in the next cycle of the program I start the sampler. This doesn't work. I have to let the PLC doing another run 1 cycle and then I can restart the sampler...

maybe a status bit would be nice to say that file is being saved, so we can use this bit for restarting the sampler...