New features wanted!! Apply here!

[franji1]

MQTT Username/Password Obfuscation
I would like to see the obfuscation of the password field in the MQTT broker password field.

We can do this for all the password fields in the System Configuration dialog boxes.  Not sure if it is helpful to do it for the user name?  That could create a lot of frustration for most customers when it's not working.  People understand hiding the password field contents - that's probably enough?

[AC]

Yes, the password field would be sufficient, and I understand leaving the username as it is trivial.
Thank you for the consideration!

[JasonO]

Any chance we'll get structured text capability in Do-More?
I see that Productivity just got that. I use Do-More/BRX for almost every project, and prefer to keep it that way. But being able to mix and match the existing ladder logic with ST, in different programs and tasks, would be a really useful feature.

[Controls Guy]

• Local variables associated with code blocks and just more name-spacey things in general
• Library support.   TIA portal has a pretty extensive library functionality; you can store almost anything in there, code blocks, configured hardware, entire PLC racks, it's pretty open
• More conventional implementation of SFC
• User symbolic boolean constants
• Add day and date to time display on trends.   I often do trends that span several days.  Right now I have to click a snapshot which includes the date
• My partner will say FBD but don't listen to him
• He also feels like the Simulator could be stronger, I can't figure out what he means.

[BobO]

Any chance we'll get structured text capability in Do-More?
I see that Productivity just got that. I use Do-More/BRX for almost every project, and prefer to keep it that way. But being able to mix and match the existing ladder logic with ST, in different programs and tasks, would be a really useful feature.

We did some prototyping of a textual language a while ago. There didn't really seem to be much demand so it got back burner-ed. If PxK demonstrates enough interest, we'd love to relight that fire. I am honestly not a fan of ST...Pascal from 1980...but once you do a parser, different textual variants may be a simple AI exercise. My personal preference (and a more modern approach) would be Java/C-like syntax.

[BobO]

• Local variables associated with code blocks and just more name-spacey things in general
• Library support.   TIA portal has a pretty extensive library functionality; you can store almost anything in there, code blocks, configured hardware, entire PLC racks, it's pretty open
• More conventional implementation of SFC
• User symbolic boolean constants
• Add day and date to time display on trends.   I often do trends that span several days.  Right now I have to click a snapshot which includes the date
• My partner will say FBD but don't listen to him
• He also feels like the Simulator could be stronger, I can't figure out what he means.

Library support is under construction now.

We've got almost a full SFC implementation in Stage now. Is the picture the issue?

The Simulator is pretty much the full engine. Obviously the UI could be greatly improved and perhaps device simulation. That would likely be a paid product though.

[Controls Guy]

Library support is under construction now.

Cool! 

We've got almost a full SFC implementation in Stage now. Is the picture the issue?

You know, it's been so long since I used Stage I don't remember.   I just have a pretty clear mental image of how the UI should work (and does in other brands).   I'll have to cook up a sample program in Stage so I can make a list of what I think works better in the other concept.  Will advise.

The Simulator is pretty much the full engine. Obviously the UI could be greatly improved and perhaps device simulation. That would likely be a paid product though.

Like I said, I've had a hard time understanding what he doesn't like about it.   I'll try talking to him some more and see if I can make heads or tails of it.

[Controls Guy]

OK, I did a little in Stage, and here's what I was able to come up with:

I wasn't able to get a Stage view, so I don't know if that's operator error or if DMD doesn't have one.  I'll do my best to recall what I though could be better.

• A more orthodox vertical flow of control vs. DL's horizontal.
• Having all the stages in one large ladder window seems less intuitive than just displaying the contents of of one stage that you click on or navigate to in the overview.
• Showing the jumps/transitions inside the stage ladder vs segregated at least a little bit seems less clear.  Also, I can't remember if they showed on the stage view.  Would prefer similar treatment.   If you set the cursor on a transition, have just that transition in it's own window.
• Can't remember how or if the DL Stage view handled divergences and convergences, iirc that may have been one of the things that didn't work well.   I'm old, bad memory.
• Lighting up active stages seemed like it worked optimally.   Maybe for converging stages, light up the transition tick as well as or instead of the stage square if that stage is done and waiting on the others to converge.

Bottom line was that, for me at least, the stage view was less intuitive at showing overall flow of control though the program than the industry standard-ish.  Ironically, the diagrams in the help topics for stage are based on the conventional presentation, like this:

[franji1]

I wasn't able to get a Stage view, so I don't know if that's operator error or if DMD doesn't have one.  I'll do my best to recall what I though could be better.

You are correct, there currently is no Stage view in Do-more Designer.

This view has been "on the shelf" since Designer 1.0.  We would also like it to be an editor, not just a "view" of any "stage" ladder program (which is what DL does).  Most likely, it would become its own "language" (ST or FBD or ?).  Possibly, you would probably be able to "view" it in "LD", but not be able to "edit" in "LD".

A more orthodox vertical flow of control vs. DL's horizontal.

Having all the stages in one large ladder window seems less intuitive than just displaying the contents of of one stage that you click on or navigate to in the overview.

Showing the jumps/transitions inside the stage ladder vs segregated at least a little bit seems less clear.  Also, I can't remember if they showed on the stage view.  Would prefer similar treatment.   If you set the cursor on a transition, have just that transition in it's own window.

So layout would be part of the project - you basically lay it out how you like it.  Not sure if we would have an "import" mechanism from LD to SG language.  All this is TBD, but these are definitely desirable features.

Can't remember how or if the DL Stage view handled divergences and convergences, iirc that may have been one of the things that didn't work well.   I'm old, bad memory.

DL has "Stage block" instructions, that were like large MLS/MLR for Stage.  These showed up as boxes in Stage View.  Not sure how they showed the dependent stages.

Lighting up active stages seemed like it worked optimally.   Maybe for converging stages, light up the transition tick as well as or instead of the stage square if that stage is done and waiting on the others to converge.

Yeah, with an actual SG language, things like this would "just work", since "transitions" would be a thing.  Probably the non-stage "convergence" condition could be displayed in a yellow highlight (vs. cyan, which would be the full "convergence" transition color whose status includes the converging stage status also?).

Currently, Designer's Project Browser with Status ON, expanding a Stage Program code block to its SG level does a pretty good job of showing the "high level" stage flow.  As you stated, Designer Ladder Status also shows Stage status on the power rail.

Bottom line was that, for me at least, the stage view was less intuitive at showing overall flow of control though the program than the industry standard-ish.

Yes, agreed.  That's why going the route of making it a "language" that is both viewable and editable will make it be much more intuitive (vs trying to make it "view only" via "reverse generate" a SFC-like flow from any kind of stage Ladder code).

[Controls Guy]

We would also like it to be an editor, not just a "view" of any "stage" ladder program (which is what DL does).  Most likely, it would become its own "language" (ST or FBD or ?).  Possibly, you would probably be able to "view" it in "LD", but not be able to "edit" in "LD".

I definitely agree that the SFC overview should be editable.   I'd actually picture top level programming design taking place in those blocks and then you program the block and transition code after the structure is at least rough-drafted.  So you're thinking not to have the SFC view be purely graphically edited, that there might be some underlying language defining the graph?

So layout would be part of the project - you basically lay it out how you like it.  Not sure if we would have an "import" mechanism from LD to SG language.  All this is TBD, but these are definitely desirable features.

Cool!

Another thing I think would be helpful is to have an exclusive divergence, like a switch case() for SFC.  Note the transitions below the bus in this divergence, in addition to the one you'd normally expect above the bus.   A lot of SFC implementations don't support this.   You'd think you could simulate this by having an empty state just below the divergence bus, but no.   By then you'd have committed to all the divergent threads so you have to run them all to completion to reconverge.  I'm thinking you'd have to  have a dedicated exclusive convergence to go with the exclusive divergence so that it knows it can proceed with only one thread complete.

Oh, and one other thing I'd like would be user-defined zooming/folding.   You could take an SFC and put it inside a single SFC block, for a coarser overview.   You'd then be able to zoom in to the full view, or maybe better would be to expand it so you can still see everything from the higher level view, but that block is no longer collapsed, but displayed in full.

[franji1]

Another thing I think would be helpful is to have an exclusive divergence, like a switch case() for SFC.  Note the transitions below the bus in this divergence, in addition to the one you'd normally expect above the bus.   A lot of SFC implementations don't support this.   You'd think you could simulate this by having an empty state just below the divergence bus, but no.   By then you'd have committed to all the divergent threads so you have to run them all to completion to reconverge.  I'm thinking you'd have to  have a dedicated exclusive convergence to go with the exclusive divergence so that it knows it can proceed with only one thread complete.

Interesting SFC language twist.  Your point about an "empty state" not semantically/logically the same - that is a good point.  "Cascading Transitions" may just need to be a thing.  Why stop at 2 levels deep, Cascading Transitions could be a huge tree?  Not sure why we could not support that concept - it's all TBD, but noteworthy.

Generally, yes, the internals of each "stage" and each "transition" would be coded in different window/editor.  Similar to DL, where the Stage Frame is a Split View, where the "Stage Flow View" is on the top and shows the stage flow with Stages and Transitions, but the bottom view is the "internal logic" of that "stage" (or for Designer, the Transition logic when top view cursor is on a Transition).

In DL, this bottom "internal logic view" is just a Ladder View.

Technically, the "internal logic view" could be LD for the Stage's logic or even another Stage PROGRAM (that itself is a split view - ha!).  For transitions, could easily be a MATH expression that results in a zero (false) or non-zero (true) condition.  or ?  Thinking out loud.

[Controls Guy]

Technically, the "internal logic view" could be LD for the Stage's logic or even another Stage PROGRAM (that itself is a split view - ha!).

Yup.  The internals could be any logic language you support.  LD and if you add them, text language or FBD.

re: the SFC in SFC, yes, either that or the collapse/expand implementation was what I was talking about with the zooming/folding comment.

[Controls Guy]

"Cascading Transitions" may just need to be a thing.  Why stop at 2 levels deep, Cascading Transitions could be a huge tree?  Not sure why we could not support that concept - it's all TBD, but noteworthy.

Talk about an interesting twist.....

[franji1]

Talk about an interesting twist.....

You started it.  If we have to support 2 levels, why not N? 

2 would have to be handled differently than a normal (1 level) transition.  Would we have to hard code in the Stage Flow editor that you could branch out of a transition AS LONG AS IT WASN'T BELOW ANOTHER TRANSITION?  We would have to complicate the UI for that situation.

Instead of limiting it to 2, embrace N, and ignore hard limitations.  Just let me draw sideways "AND ABOVE JOIN" LD rungs as a sideways transition tree   

[Controls Guy]

I'm in if you are!