Miscellaneous Do-More Questions

[plcnut]

Like this: "D[D[V0] + D[V1]] = Expression"

This would be very cool. 

[BobO]

Like this: "D[D[V0] + D[V1]] = Expression"

This would be very cool. 

Even more rope!!! Yes?

[BobO]

After some study, it will support this too: "Struct[Exp].Field = Exp", or "Block[Exp]:Cast = Exp".

The DmD side will take a bit of time...but once I figured out how to do it...the controller literally took *5 minutes*. :bows head in shame:

[Controls Guy]

Everything is do-able, the question is ROI. I have spent a bit of time thinking about this though, and I know how to do it pretty easily in the PLC. Whether I can talk Franj into the the Designer side work remains to be seen.

Cool! Woo hoo!  (If you can talk Franj into it, that is!)    

[BobO]

All of the pieces already exist, just have to assemble them. Franj is pretty reasonable in cases like that.

[plcnut]

Cool beans!
Sometimes the value/expression is the simple part; where to put it is the hard part. Once you get Franj on board, we'll be set ...what does he really like?

[franji1]

I think the "hard" part is going to be changing the "Result" parameter from a simple element type to a "blob",
e.g. from an element like D42 to an ASCII expression "D[N5*10 + MAX(V3, 9) + 0x4)]:R",
and handling old projects that do NOT have the "blob" parameter.  It's not hard, just gotta think it through.

It doesn't have to be backward compatible (i.e. Designer 1.0, 1.1, 1.2, and 1.3 cannot open 1.4 project files, but 1.4 must open 1.0, 1.1, 1.2, and 1.3 projects), so that's why it should not be that hard.

[Controls Guy]

Even more rope!!! Yes?

I'm planning on opening a rope emporium.  I'll take all you got!   

[Controls Guy]

After some study, it will support this too: "Struct[Exp].Field = Exp", or "Block[Exp]:Cast = Exp".

The coolness is almost too much to bear!  

The DmD side will take a bit of time...but once I figured out how to do it...the controller literally took *5 minutes*. :bows head in shame:

That's a sign of previous good design!  I made a functionally fairly major improvement to a DM app the other day, and it took about an hour.  The change was significant enough that the customer assumed it would take days if not a week or more.

[Controls Guy]

I exported logic from two versions of a program to difference them with an external program.  They're two forks of the same original program.  I notice in one version only, extra NOPs after a program exit that don't show in the alternate version.  On screen of course, there are nothing but NOPs after the EXIT.  Why would one get exported in one program version but not the other?  Puzzling.

[BobO]

We keep an extra NOP at the end of each code block as an insert point, or some such thing...I barely remember, and it turns out that the management of said NOP is not...um...optimally consistent. I think there might have been some effort to fix it a bunch of years ago, but it proved harder than one would expect, so we left it. It's mostly harmless...

[franji1]

I exported logic from two versions of a program to difference them with an external program.  They're two forks of the same original program.  I notice in one version only, extra NOPs after a program exit that don't show in the alternate version.  On screen of course, there are nothing but NOPs after the EXIT.  Why would one get exported in one program version but not the other?  Puzzling.

There is no extra NOP in the PLC's code-blocks, but there are in your project in Designer.

Also, if you ever cursor beyond the bottom of your program and begin editing, that will add another extra NOP.  But all of this is at the Designer level.  It's just "pad" to allow you to cursor beyond the last instruction in your program.

Adding new stuff beyond the end of existing logic needs to "just work", hence why the NOPs beyond the end "just show up".  This is just on the Designer side.  Trailing NOPs are never downloaded to the PLC.  Although it appears as though every code-block is "filled with NOPs", that is just a façade to make it easy to add logic sequentially, which is how most logic is written.

[Controls Guy]

That all makes sense, and it wouldn't even bother me if an extra NOP or two were downloaded to the PLC.  My question was the inconsistency, as well as it creating apparent differences when comparing, making real differences hard to find in show-only-differences mode or when skipping difference to difference.  Not a big deal unless it does that a lot, creating a lot of clutter.

IIRC, I believe I've seen similar behavior in the internal DMD compare (telling me there's a difference, but when I go look, I can't see any).  Perhaps that stems from the same issue.

[Controls Guy]

There is no extra NOP in the PLC's code-blocks, but there are in your project in Designer.

Does that imply that I can manually fix it (for easier compares) by deleting the rung where the extra, explicit NOP is?  Won't make any difference on screen of course, but would that then synch the exported files?

[franji1]

I misunderstood.  The issue is with Exported .TXT files?  Those are not guaranteed to match the source project code exactly.  In addition to the extra NOPs, there are hidden parameters called Edge Bits and Instruction IDs that will also be different.

Can you describe the situation(s) you are dealing with?