Any news on Studio 5000 Designer V34 yet?

JeremyM said:

Blaming the tools isn't the solution.

Click to expand...

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?

cardosocea said:

Is it really blaming the tools when there are similar tools that achieve more, at times for a fraction of cost?

Click to expand...

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?

How much Rockwell stock do you own, by the way?

Click to expand...

Apparently enough of it (zero) to set up real estate in some people's heads.

JeremyM said:

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?

Click to expand...

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.

But let's say that AOI's are indeed meant to be small instructions 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). What's the excuse for not allowing online Program Alias changes? Do all your programs work well forever out of the box?

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.

cardosocea said:

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.

Click to expand...

Code re-use becomes something of myth when it's subject to online edits.

Performance may or may not be your concern, but it is an advertised and measurable advantage when it counts.

I don't know which brands you're referring to, much less how they implement their FB mechanisms, but flexibility almost always demands a tradeoff in performance and memory.

But let's say that AOI's are indeed meant to be small instructions

Click to expand...

Not my claim.

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).

Click to expand...

They do and it's readily apparent in PAx. We do with our own, too.

What's the excuse for not allowing online Program Alias changes?

Click to expand...

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.

Being able to work with pointers to generic types (or void) would be nice.

Do all your programs work well forever out of the box?

Click to expand...

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.

For this reason, our AOIs don't encapsulate process logic or any block of code that could subject the process to unscheduled downtime.

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.

Click to expand...

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.

I don't think there's anything remarkably different about a Rockwell NIC vs a Broadcom NIC vs an Intel NIC if both are connected to EIP IO. I prefer the latter, but I'm responsible for its implementation when I commit it to an MCU.

Modern MCUs and 5x80 controllers both use ARM reference CPUs. No specialized difference, unless we're comparing M-series or A-series implementations.

Field IO is a different animal. The cute "Industrial-Arduino" GPIO can't hold a candle to its reliability, fault tolerance, or built-in diagnostic capability.

In turn, the software you use to program a PLC lets you focus on the application of the process as much as possible.

Are there shortcomings? Absolutely. Do I have a list of new features I'd love in Logix? Yes. Is an online-editable AOI on my radar? No.

Can you possibly abandon the AOI
& do it in a indexed array in one loop?

I may not appreciate how/when AOI's should be used.
They are primarily used to duplicate code over & over?

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.

I see them useful for small things like scaling.
But once it gets over a few lines long seems to not be worth it unless a product or concept is very mature & proven to be final form for the life of the machine, or it is down a lot allowing downloads.

If you abstract at a high enough level
code never needs duplicated & if you abstract @ a high level
I do not think you would ever want to lock it down in an AOI

We write code to work kind of like AOI's
Easily cut & pasted.

We also build a diag line of code so you can see real-time what valve & 3000 is doing in a busy index to make it easier for others to follow.

RowdyDoc said:

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?

Click to expand...

*Claps*


Side note: we really need a clapping Emoji

RowdyDoc said:

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

Click to expand...

Sadly decryption will not be a feature in the foreseeable future. I shant publicly say how I know this.

JeremyM said:

Write better code.

Fixing an AOI online isn’t the answer.

Click to expand...

Oh boy

Dayvieboy said:

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.

Click to expand...

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).

theColonel26 said:

Sadly decryption will not be a feature in the foreseeable future. I shant publicly say how I know this.

Click to expand...

Out of curiosity (from a non-AB guy), what's encrypted? Is it optional?

mk42 said:

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).

Click to expand...

In v33, you can set tabs side-by-side, so in this case one for the AOI's logic and the other for an instance of the backing tag.

mk42 said:

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.

Click to expand...

I believe Dayvieboy said they add a diagnostic line/rung so they can pick which index they want to monitor. I've done this to make troubleshooting in real-time easier.

mk42 said:

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).

Click to expand...

We use Siemens as well but sill seldom use AIO's
The code can still be modular, it is just a preference.

We do have a diagnostic to view a specific device in a loop if desired.
The same loop code with a static index address & [NOP]

Often we put a graphic of the diagnostic ladder on the
GUI so it does not take a programmer & a software license to troubleshoot.

mk42 said:

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?

Click to expand...

So I know for a fact that at least this revision is not going to add online AOI edit capabilities.

Shouldn't it be possible to have a controller setting that disables or enables online editing capabilities? If the original programmer doesn't want edits in the long run, can't they already lock the AOI by adding a signature? There is also an option to use source keys

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.

mk42 said:

Out of curiosity (from a non-AB guy), what's encrypted? Is it optional?

Click to expand...

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.

And just to clarify, If you re import them in to Studio 5000 you can access them normally.

Rockwell uses 1 encryption key per L5X version, this is so any instance of rockwell Studio 5000 can read the code inside and download it to a PLC. the user "Source Key" is just a software thing that confirms you are supposed to access that code. If they used a per user encryption key then a user with out the key wouldn't be able to download and run the code.

That all make sense? It has take be like a year of investigating to finally understand how all this, since they're no actually Rockwell documents that explain how source protection works behind the scenes.

PreLC said:

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.

Click to expand...

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.

theColonel26 said:

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.

Click to expand...

Agreed. CYA on the IP and liability.

theColonel26 said:

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.

Click to expand...

There's this export setting. Haven't tried it, yet.