Roald has written an excellent guide for the Twincat Eventlogger.
https://roald87.github.io/twincat/2020/11/03/twincat-eventlogger-plc-part.html
https://roald87.github.io/twincat/2021/01/20/twincat-eventlogger-hmi-part.html
For us this is exactly what we want, there is however 1 thing I haven't figured out. How to get the sourcename of the alarm in multiple languages in the HMI. params::sourceName gives the path in the software (example: MAIN.fbConveyor1.Cylinder1) This path can be customized when initializing the alarm (as Roald has shown). This doesn't work in my case, since I would like to define a generic alarm (example: "Cilinder not retracted within maximum time") that is instantiated multiple times.
I was thinking of using the source as a way to show the operator where the alarm occurs. We use this way (path) already for saving machine settings among other things. The machines we build are installed all over the world, so multilanguage is a must.
Beckhoff does support multilanguage alarm names (when defined), but the source is not defined, but dynamically generated.
Anyone have an idea how this problem can be solved?
If I understand your question correctly, then being able to parameterize the event text with information of the source of the problem should help you out.
If you define the event text as Cylinder {0} has not retracted in time. then you can add the arguments of that text during runtime.
IF bRaiseAlarm THEN
bRaiseAlarm := FALSE;
fbAlarm.ipArguments.Clear().AddString('Alice');
fbAlarm.Raise(0);
END_IF
However, since this also stated in the articles you mentioned, I am unsure if this would solve your problem.
'Alice' in this example, can be hard to localize. The following options come to my mind.
The string can be based on an ENUM. Enums can have textlist support, so if you add your translations there, that should allow multilingual output. However... this does require a lot of setup, placing translations inside your code, and making sure the PLC application is aware of the language that the parameter should use.
Use tags to mark the source device, as tags can be language invariant. It is not the most user-friendly method, but it could work for you. It would become something like: "Cylinder 'AA.1123' did not retract in time.". 'AA.1123' as a tag would have to be stored inside your PLC code as a string. You will have to trust that your operator can relate the tag back to the actual source.
Hopefully, this helped, or else please help me understand the problem better.
in yocto imagebuildscripts there is a config variable named "IMAGE_FEATURES" i want to create a custom Imagefeature.
I searched my yocto installation which runs poky for existing imagefeatures but i wasn't able to find it.
IMAGE_FEATURES is a bit special, as its basically being hardcoded into image.bbclass.
Generally you are way better off creating custom DISTRO_FEATURES, and triggering on them whereever needed. See packagegroup-core-boot as an example of a recipe changing behaviour based on DISTRO_FEATURE in various places.
Usage wise there is little difference, the only thing you can't do is set DISTRO_FEATURES in the image recipe. If that is your actual need, then you probably should pour the new functionality in a custom image class the includes and extends image.bbclassm and call it myimage.bbclass (or similar).
EDIT:
Initially, I referred to the dropbear recipe as an example that triggers behaviour based on systemd being set as DISTRO_FEATURE. This is technically correct (and it was the first recipe that came to my mind), but probably confusing as there is a dropbear spedific IMAGE_FEATURE too.
Not really critical question, but i'm curious
I am working on a form and sometimes the generated function name is /1BCDWB/SF00000473, and sometimes /1BCDWB/SF00000472. This goes back and forth.
Does anyone know what's the idea behind this? Cuz i'm quite sure it's not a bug (or i might be wrong on that).
It is not a bug. You always have to use SSF_FUNCTION_MODULE_NAME to determine the actual function module name and call it dynamically using CALL FUNCTION l_function_module.
Smartform FMs are tracked by internal numbering and thats saved in the table STXFADMI. You would always notice the different number in Development System if you have deleted any existing Form. Similarly, you would also notice the different number in your Quality system based on the sequence the forms are imported in QAS and the forms as well (as test forms are not migrated to QAS.
Similar behavior is also true for Adobe Form generated FMs.
You need to understand that every smartform has a different interface and hence the automatically generated function module needs to have different import parameters.
Due to this reason the 'SSF*' FMs generate a FM specific for your smartform. The name of the 'generated' FM changes when you migrate from one system to another. And that's the reason why you should use a variable while calling the 'generated' fm and not hardcode it.
The same goes with Adobe form as someone has rightly said in this thread.
Without using a source-filter, is there a way to change the current running package? I'm trying to accomplish the same thing oose.pm does, and I'm wondering if I can drop my users in a non-main package.
I think you'll be able to do that by changing PL_curstash and PL_curstname on the C level.
PL_curstash = gv_stashpvs("Some::Package", GV_ADD);
sv_setpvs(PL_curstname, "Some::Package");
PL_curstash is the stash of the current package during compilation, PL_curstname is its name.
Update:
I've found this problem kind of interesting and implemented the solution as Devel::ChangePackage. Turns out what I initially suggested just works. You can get it either from http://github.com/rafl/devel-changepackage, or from a CPAN mirror near you once they have updated.
Some of the developers on the project I work on have a habit of commenting their code to show which version of the product it was added for, e.g.
// added for superEnterpriseyWonder v2.5
string superMappingTag = MakeTag(extras);
if (superMappingTag.empty())
{
autoMapping = false;
}
// end added for superEnterpriseyWonder v2.5
Whenever I see this my blood pressure rises, and I have to spend 5 minutes browsing SO to cool off. It seems to me that they don't understand version control and if I were to use this practice too every other line in the source files would be a comment about when things were added. I'm considering removing all such comments from files that I work on, but am wondering is it just me being picky and is there actually some value to these comments?
If you're using Source Control then I would advocate adding a build label to Source Control after every build. That way you can search for all source modified for a specific build, with no nasty comments clogging your code.
This from Clean Code, a book by Bob Martin:
"The proper use of comments is to
compensate for our failure to express
ourself in code. Note that I used the
word failure. I meant it. Comments are
always failures."
I always think of that quote when I see a comment so I'm not suprised your blood boils.
No value whatsoever. If you have a blame tool in your version control this will achieve this, they just add noise.
Whats worse is they will attract further comments to your code to make it completely unreadable
// added for superEnterpriseyWonder v2.5
string superMappingTag = MakeTag(extras);
if (superMappingTag.empty())
{
// bug fix #12345674 shuld have been true
autoMapping = true;
// bug fix #12345674 should have been true
i++; // v2.6 now need to up the counter DO NOT DELETE
}
// end added for superEnterpriseyWonder v2.5
and then someone will delete the method but leave the code comment in
// added for superEnterpriseyWonder v2.5
// bug fix #12345674 should have been true
// v2.6 now need to up the counter DO NOT DELETE
// end added for superEnterpriseyWonder v2.5
Just say no to crappy comments
I'd say there's no value: This info can also be retrieved with your SCM's annotate/blame functionality. Also, anyone can add text between these comments, which make the comments dated (since you might add something for v2.6 while the comments say v2.5)
Another thing to note is that these comments are essentially hidden: You only see them when you are looking at the source code in question, so you can't use it to generate a changelog or something.
The comment as shown, is probably not to useful. However, there may be times that adding a feature may cause the addition of not so obvious code. In which case, a comment describing the change and/or why it the code is not obvious would be appropriate.
Not only is there no value here...there's negative value. Maintenance of comments is already sketchy in most places, this just adds another thing for people to screw with. These comments have no value to the reader and are therefore clogging their brain up with useless version information when they could have another line of code in their memory. It's also another line to have a merge conflict on (totally not joking here..I've seen merge conflicts on comments).
Could be useful in some cases (e.g. if this helps to understand why some function works differently in V3 than in V2) but in general, it's the job of the SCM to know what has been added when.
You are not picky IMHO. There are at least three good reasons not to add this type of comment in source code:
their place is actually in a Version Control System, where you can have a global view of everything that has changed to accommodate a new version of a library or a new feature. Provided it is done correctly and the logs are used.
if the source code is part of the deliverables to clients, maybe they don't need to know the history of what happened. Imagine you have done a modification for another client, and put that in comments!
too many comments are no better than too few.
The line is not clear though, what would be the difference between
// Compliance with specs abc (additional xyz feature)
...
... // some code
and:
// xyz feature:
...
... // some code
In general terms, I would not put anything that is related to the history in the source code, but stick to commenting what is done, how it is done, so that someone else can easily browse through the code and understand it.
My advice: have a methodology document written, or an informal discussion.
If seeing a superfluos comment makes your blood pressure rise, you need to take up drinking or something.
That said, I agree that such comments are mostly useless. If used consistently, the program would quickly become a maze of such comments. What if a line is changed once for version 2.5 and then a year later changed again for bug 3294? Do you put two "version" comments on the same line, or just keep the latest? If you only keep the latest, then you've lost the fact that this was originally added for 2.5. If you keep them both, what happens when there's a third change or a fourth? How do we know what the state was at each change? What happens when you add a block of code in version 2.5, and then for version 2.6 you add another block of code embedded within the 2.5 block? Etc etc. The program could easily end up having more version comments than lines of code.
If not done consistently, the comments would quickly become misleading. Someone could put a comment saying this block was added for 2.5, someone else could insert code inside that block for version 2.6 and not comment it, and now we have a comment that seems to say that the second block was added for 2.5.
And do we care that much? It's pretty rare that I care when a change was made. Oh, okay a couple of weeks ago I cared because I wanted to know who to blame for a major screw up.
As others have pointed out, version control systems do this for you on the rare occasions when you need it. I guess if you didn't have any sort of VCS, a case could be made for doing this. But you can get some very nice VCSs for free. If you need one, get one. Otherwise you're like the people who say that you should practice doing arithmetic in your head because otherwise what would you do if your calculator quit working. The assumption apparently being that at any moment, all the calculators in the world might simultaneously break.
You might say that it can help to be able to say, "Ohhhh, this was added to order entry to support the new salesman timecard function" or some such. But then the important this is not "This code was changed by Bob for version 3.2.4", but rather, "This code produces this data which isn't used here but is needed by another module over there".
I am a firm believer in writing comments that introduce sections of code and describe the general idea behind complex or otherwise non-obvious code. But that's an entirely different thing.
Consider that some may have to grab snapshots from the VCS. In that case, they don't have history to fall back on .. and such comments become useful.
I saw that a lot in code written by people that didn't use version control until recently. I guess they just took the habit and now it's hard to stop.
Another reason I found was that sometime it is important to know what piece of code is associated with what version. Of course you can always check the version log, but you don't always have time for that, and it's annoying. In some cases saying "code for v3.2" speaks more to other developers than "code to do x, y and z"... it all depends on the conventions established by the team.
Another answer is that in some projects I worked with some code was commented like that, but it was before the project actually started using version control. In that case it also made sense to keep it that way.
I find them useful, it saves chasing through the VCS to find out why a change was made to the code, or to find the BugId for a defect, given I remember what the code change was.
Although in theory the VCS contains the information, in practice it can get buried, particularly by integrations.
In other works which is easier:
// DEF43562 - changed default value
foobar = true
Or
blame(or equiv)
chase through
history to find the correct change.
Follow integration to source, and
repeat 1&2.
Find bug id attached
to original change, if you are
lucky.
Basically the comment is a short-cut around the VCS, and flaky VCS/BugTracking integration.
I find that the comments are also useful as a marker for: "This decision has been reviewed by customers/users/review committee, and this is the selected answer, be careful about changing the behaviour".