Is there a way for a PLC program to know its own cycle time?
As a workaround, I can just add a persistent variable or a constant to tell it manually, but that's obviously error prone.
To add to Jakob's answer - you can also use GETCURTASKINDEXEX function (Infosys) instead of GETCURTASKINDEX FB. This way you don't have to instantiate it.
_TaskInfo[GETCURTASKINDEXEX()].CycleTime
Will return cycle time as multiples of 100ns (UDINT)
UDINT_TO_LREAL(_TaskInfo[GETCURTASKINDEXEX()].CycleTime) / 10_000_000
Will return cycle time as seconds (LREAL)
For TwinCAT3 this is available in PlcTaskSystemInfo (variable CycleTime).
Combine it with the FB GETCURTASKINDEX to get the data you want.
See one example (though not cycle-time, but still same FB) here at AllTwinCAT.
This is not directly an answer to your question, but can be used to determine the Cycle time.
I like to use the Time() function. It returns a value of data type TIME. It does not represent an absolute time, but can be used to calculate the time between two calls to Time(). In this way you can calculate the Cycle time.
I use it in function blocks (FB) where timing is critical. In this way the FB knows when it was lastly called instead of assuming that it is being run each scan. Even if I or another user of my FB "forgets" to call the FB each scan, the FB still delivers correct outputs.
You can find info on Time() using this link. There is also a function called LTime() which returns a value of data type LTIME, but it seems that Beckhoff did not bother to document this function.
Related
I have seen a few different documentations refer to the term "callbacks" (Flux.jl and some SciML packages) but it is not clear what that means in the context of Julia.
I know that a callback is a function passed as an argument to another function but is there more to it than that? What would the use case for such a paradigm be?
A classic example of use of a callback is the progress bar. A callback is supplied to the function that is doing work within some kind of sequence. At regular intervals during the sequence the callback is called with some kind of information about the work being done (the percent completed in the case of the progress bar, which updates a progress display).
Flux can call a callback each time it completes a segment of training, or in the example in the source code, every 10 seconds:
https://github.com/FluxML/Flux.jl/blob/b78a27b01c9629099adb059a98657b995760b617/src/optimise/train.jl#L80-L95
So for my project in area of Industrial Engineering, I am making a warehouse simulation and optimization model in software Anylogic. I want to know the time my picker spends in being busy( that is moving) and so I came across this built-in function 'timeInState'. This helps me to determine the total time by picker has spent being 'busy'.
The issue I am facing is that upon calling this function, I am getting no value (0), but my pickers are clearly moving in the model. Maybe the parameters I am giving is not the right way to do it. I was thinking if anyone familiar with this can help me out? . To clarify the function, its meaning and parameter initialization is as below:
double timeInState(ResourceUsageState state) -Returns the time the unit has spent in the given "usage state" so far.
Parameter: state - the state (ResourceUsageState.USAGE_IDLE or ResourceUsageState.USAGE_BUSY)
Thanks for your help !
The timeInState function has nothing to do with state charts but records durations for resources. It is named rather unfortunately...
There is no build-in way to measure state durations (for good reasons ;-) ).
Easiest solution:
create a double variable timer and another timeInStateX
on-enter of your state X, set timer=time()
on-exit of your state X, add the duration as timeInStateX += (time()-timer
Make sure to not accidentally overwrite the timer from elsewhere, though
The timeInState function does work to capture time busy so you must have another problem. You should be calling it similarly to <resource reference>.timeInState(ResourceUsageState.USAGE_BUSY) or (specifying time units) <resource reference>.timeInState(ResourceUsageState.USAGE_BUSY, TimeUnits.MINUTE).
You'll need to give more context to understand why it's not working for you.
You are also seizing and releasing these agents as resources in a ResourcePool right?
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.
I have just started to work with PLCs and I need to modify parameters of a sinamics from a PLC. I know that they may have different accesible levels and that they are modified by functions. So the question is:
Can I the parameters be directly modified?
Or if it is not possible, how do I programm and include that functions?
At least try to find some information.
http://support.automation.siemens.com/WW/view/en/34677186/136000&cspltfrm=39&cssw=0&csbinh=8
Sinamics drives parameters can be modified from the plc code using _writedriveparameter function.
One thing to remember is: never use this function in two places at the same time. If you do it the function hangs and to restore the correct working it is necessary to reboot the cpu.
Also remember to check the function result to call the function in the correct way (result 7001,7002,7003 ecc). You have to check if the function is already working or not.
I'm fairly new to using Google Docs, but I have come to really appreciate it. The scripting is pretty easy to accomplish simple tasks, but I have come to realize a potential speed issue that is a little frustrating.
I've got a sheet that I use for my business to calculate the cost of certain materials on a jobsite. It works great, but was a little tedious to clear between jobs so I wrote a simple script to clear the ranges (defined by me and referenced by name) that I needed emptied.
Once again, worked great. The only problem with it is that clearing a few ranges (seven) ends up taking about ten full seconds. I -believe- that this is because the spreadsheet is being saved after each range is cleared, which becomes time intensive.
What I'd like to do is test this theory by disabling autosave in the script, and then re enabling it after the ranges have been cleared. I don't know if this is even possible because I haven't seen a function in the API to do it, but if it is I'd love to know about it.
Edit: this is the function I'm using as it stands. I've tried rewriting it a couple of times to be more concise and less API call intensive, but so far I haven't had any luck in reducing the time it takes to process the calls.
function clearSheet() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var sheet = ss.getActiveSheet();
sheet.getRange("client").clear();
sheet.getRange("lm_group_1").clear({contentsOnly:true});
sheet.getRange("lm_group_2").clear({contentsOnly:true});
sheet.getRange("dr_group_1").clear({contentsOnly:true});
sheet.getRange("dr_group_2").clear({contentsOnly:true});
sheet.getRange("fr_group_1").clear({contentsOnly:true});
sheet.getRange("fr_group_2").clear({contentsOnly:true});
sheet.getRange("gr_group_1").clear({contentsOnly:true});
sheet.getRange("client_name").activate();
}
That is not possible, and will probably never be. It's not "the nature" for Google Docs.
But depending on how you wrote your script, it's probable that all changes are already being wrote at once, in the end. There's some API calls that may be forcing a flush of your writings to the spreadsheet (like trying to read after you wrote something), but we'd need to see your code to check that.
Anyway, you can always check the spreadsheet revision history to verify if it's being done at once or in multiple steps.
About the performance, Apps Scripts have a natural delay that is unavoidable, but it's not 10s, so there's probably room to improve on your script, using fewer API calls and preferring batch calls like setValues over setValue and so on. But then again, we'd have to see your code to assert that and give more helpful tips.