(CoDeSys) xDone bit remains TRUE

[AlfredoQuintero]

Hello. I have struggled all my Saturday with this one issue, and it is clear that only someone far more knowledgeable than me on CoDeSys can possibly clarify this to me. Please feel free to scold me and educate me. I prefer to sacrify my dignity if I can get this right.
I purchased a library from CoDeSys which has a number of functions to read and write text files. I was able to get the write part relatively painlessly, but I am having an issue with reading data from CSV files.
One particular function (CSV.NextElement) does not work in my program the way it does in the sample provided by CoDeSys with the product. In the CoDeSys sample, when the function is called if there are no errors the xDone and xBusy bits go TRUE and then FALSE, and it can be called again, reading the data as expected from the configured CSV file.
But in my program, after it calls the CSV.NExtElement function, the xDone bit remains TRUE. I found that if I call the same function instance again with the "xExcute := FALSE", then calling the same instance will read the next element of my CSV file, which is what I need.
Why? What can I be possibly doing wrong for this function's behaviour to look different in the sample and mine.
Thanks. Below is an illustration.

 

[drbitboy]

is xExecute supposed to be a one-shot?

 

[AustralIan]

This is the common behaviour model. Most function blocks are to be designed like this, so you should familiarise yourself with their operation.

Some reading would be:
https://help.codesys.com/webapp/behaviour_model;product=LibDevSummary;version=3.5.17.0

and going to https://plcopen.org/downloads and searching for "compliant" will give you two results. You can read either just the 4 page one, or both, depending on how much you like reading.

You are right that you need a false to true transition to trigger the next processing.

 

[AlfredoQuintero]

is xExecute supposed to be a one-shot?

Hi drbitboy. Thanks for responding. Everything is very clearly explained in the articles pointed by AustralIan. For this function the xExecute input is activated when a rising edge is detected. I think I have solved my problem.

 

[AlfredoQuintero]

This is the common behaviour model. Most function blocks are to be designed like this, so you should familiarise yourself with their operation.

Some reading would be:
https://help.codesys.com/webapp/behaviour_model;product=LibDevSummary;version=3.5.17.0

and going to https://plcopen.org/downloads and searching for "compliant" will give you two results. You can read either just the 4 page one, or both, depending on how much you like reading.

You are right that you need a false to true transition to trigger the next processing.

Thanks very much for pointing me to these articles and for your clarifications. It seems the sample from CoDeSys for the CSV library is very simple, and in that case the PLC application runs a full cycle before it is called again. This provided a hint, and I think I have solved my problem. I am glad I purchased this library. Developing this from scratch is out of my league. As always, your assistance was extremely helpful. Not only for the understanding of this CSV library, but for the "Common Behaviour Model" concept of the PLCOpen standard.

 

[lostcontrol]

Hi Alfredo,
Do you have any samples of reading files into codeys from a rPi.?
I’m experimenting at the moment & cannot get tbr simple file size to register .
There is a tip on the source forge forum that says the reading must be from $$plcLogic$$’ instead of var/opt/codeys, which does appear to make a different to some of the results.

There is obviously some thing I’m missing, assuming it can be done in the rPi easily..