I need to increment an integer value each time the PLC program is updated to track changes.
There are system events like online_change and before_download, but I have no idea how to implement their functions.
Also I need to save value between updates. I think the tracking variable should be created as RETAIN but not sure.
The variable declaration type should be VAR RETAIN PERSISTENT in your case. Variables declared under RETAIN only will lose their values (intentionally) with a program change.
I believe the builtin Codesys library SysLibProjectInfo.lib has what you are looking for with the function SysGetProjectID. If you store SysGetProjectID as a RETAIN PERSISTENT and then compare against it, you can track changes (or, this unique value may be exactly what you wanted in the first place, without manually creating an ID).
Note: Depending on how you declare your variables, changing the I/O configuration can have unexpected changes even on VAR RETAIN PERSISTENT variables (as all dynamically allocated addresses are shifted and may not point where they used to).
If I understand you you only want to know like what version is running on the PLC and you want to track changes that you make? You can do it two ways:
Since it's a constant each time you make a change external to the PLC you roll the rev of a variable that is declared like SoftwareVersion :WORD := 100; and keep it in a Revision global list that you can add your notes to and change the version before downloading to PLC.
You can also use the PLC summary area that has fields to enter the values and then you can read them through CoDeSys without software upload.
And of course the suggestion above can work.
Related
Hi I am studying computer architecture. We learned that we usually use temporary registser($t) to temporarily store values in registers. However, I saw a data that uses the stack pointer ($sp) to temporarily store the value of the saved register ($s) in the function. Can't we just use temporary register($t) instead of this? I think the stack pointer and the temporary register do the same thing, but I'm curious what exactly is the difference between the two.
I'm using WAGO PLC PFC200 in my home automation project. I've plenty of POUs, each for one room. Each room implements IRoom interface and uses base POU for common logic like turning off all lights.
For lights management, I'm using
FbEvaluateShortLongPress from WagoAppBuilding to handle short and long press of buttons on the wall (it could also be a function block from OSCAT library)
FbLatchingRelay from WagoAppBuilding as a toggle for PLC digital output
I want to save the state of FbLatchingRelay in case of e.g.: power drop. I want all lights which were turned off before power drop to be turned on when the power comes back.
I've solved it by declaring a FbLatchingRelay in the VAR RETAIN PERSISTENT area in my POU. But then after reading here that:
If you declare a local variable in a function block as RETAIN, CODESYS stores the complete instance of this function block in the Retain range (all data of the function block); however, only the declared RETAIN variable is treated as such.
I decided to change that in order not to waste RETAIN memory for a bunch of variables which are in POU but are not needed to be stored as RETAIN.
So right now I have something like that:
the VAR RETAIN PERSISTENT area is only declared in my main program
it stores structures for each room (each POU) only with needed data - FbLatchingRelay POU and few other variables
while initializing the room (POU) I'm passing those structures to my rooms using VAR_IN_OUT
each room (POU) uses then this data
PLC_PRG:
VAR RETAIN PERSISTENT
BathroomPersistentData: BathroomData;
END_VAR
Bathroom(PersistData := BathroomPersistentData, xMainLightSwitch := DI1_13, xMirrorLightSwitch := DI2_3, xMirrorLightSwitchActuator => DO2_1, xMainLightSwitchActuator => DO1_11);
Bathroom POU:
VAR_IN_OUT
PersistData: BathroomData;
END_VAR
Is this a good approach? What do you think? It complicates project a bit but I'm not wasting RETAIN memory for things which should not be there (whole POUs).
Yes, this is how my organization handles retain vars. This also lends itself to supporting “save to disk” solutions for other FB demands (not so much for your light states).
On the other hand, did you run out of memory by the original way? Sometimes I find we worry about things that never happen. Yes it is “wasteful” for the whole FB instance to be put in retain memory, but if your FBs are small and your device has plenty of retain memory - then nothing to worry about until later.
I am using libnodave 0.8.4.4 library to connect to a S7 PLC and what I would like to know if how can I detect if a bit (e.g. DB100.DBX8.0) in PLC DB changes its value. What I did is to read this bit within a while loop but I would like to create an event on value changed on this bit and launch a task when it happens.
There is no default event available with libnodave or any other libraries like S7.net.
Either you need to use OPCor write your own function which will read the set of bits set on time and notify to the main program.
I have to work with a lot of data and run the same MATLAB program more than once, and every time the program is run it will store the data in the same preset variables. The problem is, every time the program is run the values are overwritten and replaced, most likely because all the variables are type double and are not a matrix. I know how to make a variable that can store multiple values in a program, but only when the program is run once.
This is the code I am able to provide:
volED = reconstructVolume(maskAlignedED1,maskAlignedED2,maskAlignedED3,res)
volMean = (volED1+volED2+volES3)/3
strokeVol = volED-volES
EF = strokeVol/volED*100
The program I am running depends on a ton more MATLAB files that I cannot provide at this moment, however I believe the double variables strokeVol and EF are created at this instant. How do I create a variable that will store multiple values and keep adding the values every time the program is run?
The reason your variables are "overwritten" with each run is that every function (or standalone program) has its own workspace where the local variables are located, and these local variables cease to exist when the function (or standalone program) returns/terminates. In order to preserve the value of a variable, you have to return it from your function. Since MATLAB passes its variables by value (rather than reference), you have to explicitly provide a vector (or more generally, an array) as input and output from your function if you want to have a cumulative set of data in your calling workspace. But it all depends on whether you have a function or a deployed program.
Assuming your program is a function
If your function is now declared as something like
function strokefraction(inputvars)
you can change its definition to
function [EFvec]=strokefraction(inputvars,EFvec)
%... code here ...
%volES initialized somewhere
volED = reconstructVolume(maskAlignedED1,maskAlignedED2,maskAlignedED3,res);
volMean = (volED1+volED2+volES3)/3;
strokeVol = volED-volES;
EF = strokeVol/volED*100;
EFvec = [EFvec; EF]; %add EF to output (column) vector
Note that it's legal to have the same name for an input and an output variable. Now, when you call your function (from MATLAB or from another function) each time, you add the vector to its call, like this:
EFvec=[]; %initialize with empty vector
for k=1:ndata %simulate several calls
inputvar=inputvarvector(k); %meaning that the input changes
EFvec=strokefraction(inputvar,EFvec);
end
and you will see that the size of EFvec grows from call to call, saving the output from each run. If you want to save several variables or arrays, do the same (for arrays, you can always introduce an input/output array with one more dimension for this purpose, but you probably have to use explicit indexing instead of just shoving the next EF value to the bottom of your vector).
Note that if your input/output array eventually grows large, then it will cost you a lot of time to keep allocating the necessary memory by small chunks. You could then choose to allocate the EFvec (or equivalent) array instead of initializing it to [], and introduce a counter variable telling you where to overwrite the next data points.
Disclaimer: what I said about the workspace of functions is only true for local variables. You could also define a global EFvec in your function and on your workspace, and then you don't have to pass it in and out of the function. As I haven't yet seen a problem which actually needed the use of global variables, I would avoid this option. Then you also have persistent variables, which are basically globals with their scope limited to their own workspace (run help global and help persistent in MATLAB if you'd like to know more, these help pages are surprisingly informative compared to usual help entries).
Assuming your program is a standalone (deployed) program
While I don't have any experience with standalone MATLAB programs, it seems to me that it would be hard to do what you want for that. A MathWorks Support answer suggests that you can pass variables to standalone programs, but only as you would pass to a shell script. By this I mean that you have to pass filenames or explicit numbers (but this makes sense, as there is no MATLAB workspace in the first place). This implies that in order to keep a cumulative set of output from your program you would probably have to store those in a file. This might not be so painful: opening a file to append the next set of data is straightforward (I don't know about issues such as efficiency, and anyway this all depends on how much data and how many runs of your function we're talking about).
Say I have a project which is comprised of:
A main script that handles all of the running of my simulation
Several smaller functions
A couple of structs containing the data
Within the script I will be accessing the functions many times within for loops (some over a thousand times within the minute long simulation). Each function is also looking for data contained with a struct files as part of their calculations, which are usually parameters that are fixed over the course of the simulation, however need to be varied manually between runs to observe the effects.
As typically these functions form the bulk of the runtime I'm trying to save time, as my simulation can't quite run at real-time as it stands (the ultimate goal), and I lose alot of time passing variables/parameters around functions. So I've had three ideas to try and do this:
Load the structs in the main simulation, then pass each variable in turn to the function in the form of a large argument (the current solution).
Load the structs every time the function is called.
Define the structs as global variables.
In terms of both the efficiency of the system (most relevent as the project develops), and possibly as I'm no expert programmer from a "good practise" perspective what is the best solution for this? Is there another option that I have not considered?
As mentioned above in the comments - the 1st item is best one.
Have you used the profiler to find out where you code takes most of its time?
profile on
% run your code
profile viewer
Note: if you are modifying your input struct in your child functions -> this will take more time, but if you are just referencing them then that should not be a problem.
Matlab does what's known as a "lazy copy" when passing arguments between functions. This means that it passes a pointer to the data to the function, rather than creating a new instance of that data, which is very efficient memory- and speed-wise. However, if you make any alteration to that data inside the subroutine, then it has to make a new instance of that argument so as to not overwrite the argument's value in the main function. Your response to matlabgui indicates you're doing just that. So, the subroutine may be making an entire new struct every time it's called, even though it's only modifying a small part of that struct's values.
If your subroutine is altering a small part of the array, then your best bet is to just pass that small part to it, then assign your outputs. For instance,
[modified_array] = somesubroutine(struct.original_array);
struct.original_array=modified_array;
You can also do this in just one line. Conceptually, the less data you pass to the subroutine, the smaller the memory footprint is. I'd also recommend reading up on in-place operations, as it relates to this.
Also, as a general rule, don't use global variables in Matlab. I have not personally experienced, nor read of an instance in which they were genuinely faster.