cardosocea
Member
Blaming the tools isn't the solution.
Is it really blaming the tools when there are similar tools that achieve more, at times for a fraction of cost?
How much Rockwell stock do you own, by the way?
Blaming the tools isn't the solution.
I'm not disputing this. What I'm stating is that, with whatever tool you use, there shouldn't be room for half-baked nonsense. AOIs get you as close to the metal in terms of performance as you can (so far) get with Logix. The tradeoff is that it is a compiled, fixed function.Is it really blaming the tools when there are similar tools that achieve more, at times for a fraction of cost?
How much Rockwell stock do you own, by the way?
I'm not disputing this. What I'm stating is that, with whatever tool you use, there shouldn't be room for half-baked nonsense. AOIs get you as close to the metal in terms of performance as you can (so far) get with Logix. The tradeoff is that it is a compiled, fixed function.
Should we clamor for editable, online binary edits with MCUs? Maybe we should be able tweak the intrinsic ADD, SUB, and MOV, too?
Code re-use becomes something of myth when it's subject to online edits.You do understand that the concept of a Function Block is code re-use, not getting close to the metal since that's not a concern for most, if not all, people using these PLCs. Interestingly enough, other brands compile their FBs and still allow online changes to them, so I don't buy that excuse.
Not my claim.But let's say that AOI's are indeed meant to be small instructions
They do and it's readily apparent in PAx. We do with our own, too.or unbelievably configurable ones for every use case with hundreds of hours of testing
(bear in mind that not even Rockwell devotes this kind of testing time to their AOI's).
I don't know. If I had to venture a guess, it would be that the volatility of the pointer could subject referencing code to unpredictable outcomes.What's the excuse for not allowing online Program Alias changes?
We do our best to make our programming scalable past the initial needs of the project while keeping the online edit door as far open as possible.Do all your programs work well forever out of the box?
It's because most, if not all, of the hardware interface is written for you. And the 100% of the hardware design is done. This is not a trivial task.There's a reason an MCU isn't priced as a PLC is... but you obviously know it and are trying to make a point.
*Claps*I can cause major consequences with high risk to my plant with online changes that are not an AOI change. Likewise I can make changes to an AOI with very low risk (eg my dry tonnes per hour calc block that has this annoying little bug and only impacts data displayed and reported).
If the argument is that Rockwell have to protect us from our own stupidity / recklessness, then maybe they should prevent ALL online changes?
Sadly decryption will not be a feature in the foreseeable future. I shant publicly say how I know this.Doesn't the CLI tool allow us to export to L5X also? I really hope the SDK supports that and that there is an option for me to run as a FT Directory priv user and export to L5X with the encryption turned off.
That way I can automate an export of the L5X of my secured processors and then execute my parsing tool on the L5X to extract out all of the object (AOI) parameters to allow me to audit vs our specification database (all triggered by a detection of a logic change in the processor at SCADA).
You know - do something a bit 21st century...
Apologies for the cynicism - too many decades of disappointment
Write better code.
Fixing an AOI online isn’t the answer.
They seem being very problematic for many reasons on several customer sites requiring write arounds if you cannot download.
Even if you can download you may only get 1 chance to fix it.
Sadly decryption will not be a feature in the foreseeable future. I shant publicly say how I know this.
The editor will show you one set of data (probably either the first or last instance), but you can't control which.In Siemens, at least, with functions or function blocks you can monitor a specific instance of the call, to pick which valve you're checking. I assume AB is the same with AOIs(if not, add that too the wish list as well).
The advantage of the modular code (aoi/function/etc) vs a loop is that it can make it much easier to troubleshoot one instance of the code. If you wrote some valve management code for 13 valves, and you want to know why valve #7 won't turn on, you don't have any way to actually monitor the logic if you loop it. The editor will show you one set of data (probably either the first or last instance), but you can't control which.
And that's why people want to be able to do online edits on AOIs, to avoid that precise issue. If you take away the need to do a full reset to make a quick change, AOIs become a lot less scary. I do it in Siemens every day, and it's great.
The advantage of the modular code (aoi/function/etc) vs a loop is that it can make it much easier to troubleshoot one instance of the code. If you wrote some valve management code for 13 valves, and you want to know why valve #7 won't turn on, you don't have any way to actually monitor the logic if you loop it. The editor will show you one set of data (probably either the first or last instance), but you can't control which. In Siemens, at least, with functions or function blocks you can monitor a specific instance of the call, to pick which valve you're checking. I assume AB is the same with AOIs(if not, add that too the wish list as well).
And that's why people want to be able to do online edits on AOIs, to avoid that precise issue. If you take away the need to do a full reset to make a quick change, AOIs become a lot less scary. I do it in Siemens every day, and it's great.
The advantage of the modular code (aoi/function/etc) vs a loop is that it can make it much easier to troubleshoot one instance of the code. If you wrote some valve management code for 13 valves, and you want to know why valve #7 won't turn on, you don't have any way to actually monitor the logic if you loop it. The editor will show you one set of data (probably either the first or last instance), but you can't control which.In Siemens, at least, with functions or function blocks you can monitor a specific instance of the call, to pick which valve you're checking. I assume AB is the same with AOIs(if not, add that too the wish list as well).
Out of curiosity (from a non-AB guy), what's encrypted? Is it optional?
Out of curiosity (from a non-AB guy), what's encrypted? Is it optional?
You're an plant support engineer if IIRC.I don't agree with locking any part of source code(Making changes is a risk the programmers are taking)As long as people get flexibilities into what their machines can do. But adding capabilities in Rockwell infrastructure isn't a bad thing.
You're an plant support engineer if IIRC.
Let me explain the Machine OEM perspective on this.
Locking code so that it is closed source is not to keep the plant from seeing the code, it is to keep the OEMs competitors from seeing the code if they have access to that PLC/ACD because they are at the plant working on another project. We really don't care if the plant see it, and I fully understand it can be helpful with trouble shooting.
As for locking code so that it is visible but not editable, this is for the OEMs own protection. OEMs do not want some plant engineer editing things they think they understand but really don't, and then when they screw something up blaming the OEM for it. I know, I know, people would never try to cover their own *** by blaming a contractor.....
However with more OEMs adopting version control, I think this will be less of a fear.
With the things c o p i a is working on for tracking changes on the PLC, and being able to compare what is on the PLC with what was last released to the PLC by the OEM, I think we will probably stop locking sections for edit within a year or so. But we will still be source protecting so our competitors can't see our code. However we supply customer specific source keys upon requests if they will sign an NDA.
The Encryption I am speaking of is source code protection. If you have code sections that are source protected in a PLC project (.ACD) when you export it to L5X those sections are exported as an encrypted block.
You don't have to have anything source protected, but if you do and want to export it, you have to manually remove the source protection before you export it, or live with not being able to read or edit those sections as text.