Compile Error

[RBPLC]

As I'm just beginning to work with DMD, could someone please explain the following to me:
I've attached two snippits of code I'm working with. The first has the timer T28.Done on two rows attached to c1007 and y77. This code will not compile and gives the error message "Compile Error: ORing two complex output elements which aren't AND's or JOIN's". This code was taken directly from another programmers program running on another hardware platform. The second snippit shows this code with the two T28.Done's combined into one. Functionally they're the same but one will not compile. In DMD why will one compile and the other not? What are the general rules for and/or logic like this? 

[BobO]

The first PIC will do what you are trying to do.
The reason you got the error, has to do with the ladder compiler being old and outdated.Kind of ironic, because the rest of the plc is leaps and bounds ahead of the competition.IMO
The second picture is a work around the compiler handicap.
https://forum.hosteng.com/index.php?topic=2266.msg18960#msg18960

Old and outdated is kind of harsh. Specifically it's a limitation of the stack based logic implementation, which is ridiculously fast. We have a plan to work around it, but it requires touching some code that we don't want to risk breaking.

[RBPLC]

So in this instance (picture attached), I get the error "Compiler Error: Trying to AND above a JOIN". What is the "cleanest" and easiest way to do this?

[RBPLC]

I didn't think this was going to be a big deal to start with but these compile errors are actually quite annoying for what should be straight-forward logic. To me this inability to handle OR logic is something that definitely needs to be addressed. I just tried to compile a rung with three OR's in it and DMD just broke these OR's and put them on different rungs. For reference the first image is what I'm trying to do and the second image is what DMD did to the code when trying to compile it.

[b_carlton]

It doesn't sound like it will be changed to everyone's satisfaction any time soon.

I dealt with it when starting with the DL line when 'PLCDirect' first began marketing in the 90s. It took a couple minutes to make the mental switch compared to AB. Besides Stage programming offered so many advantages this was relatively trivial.

On another thought I wonder if the message in the error window could provide another link to the help file information on the specific error?

[RBPLC]

I'm trying to map this program directly over from a Mitsubishi PLC. I was trying to keep the program as much the same as possible. Seeing as how I'm not going to be able to do that in DMD, could you give me an example of the cleanest way to get an equivalent section of code. I didn't want to have c264, c102 and c115 on every rung.

[BobO]

Those bits describe some kind of state, which when implemented in old school PLCs result in that type of logic. We use stages, tasks, and programs to manage states and sequences. Much easier to read and debug.

[RBPLC]

So am I to understand that the preferred method for dealing with this type of logic is to stage it?

[BobO]

So am I to understand that the preferred method for dealing with this type of logic is to stage it?

I see a couple of things in that logic that suggests a sequence of events. We prefer to use stages for sequence.

That isn't to say that you must, or even should, just that we are big believers in using stage for sequence oriented programming.

[b_carlton]

Terminate the first part of the rung with an OUT to a new discrete bit. Use a NO of that but to beging each of the next rungs.

[RBPLC]

If, while attempting to compile, DMD either won't compile or rearranges the code (and breaks in the process) then to me it seems that DMD is essentially requiring the use of stages or many additional bits/logical expressions to accomplish the same task. So yes I don't have to to use stages but I'm certainly not allowed to use the fewer number of expressions that can be used in other programming environments.   

[RBPLC]

b_carlton
Yes that's one way to get around it but requires generation of another bit. So not ideal. I'm not opposed to trying to use stages to accomplish these tasks, I just didn't realize this was a limitation of DMD based on my limited experience with it.

[BobO]

If, while attempting to compile, DMD either won't compile or rearranges the code (and breaks in the process) then to me it seems that DMD is essentially requiring the use of stages or many additional bits/logical expressions to accomplish the same task. So yes I don't have to to use stages but I'm certainly not allowed to use the fewer number of expressions that can be used in other programming environments.

One of your issues appeared to be a bug, but I'm gonna refer to Franj when he is back in the office. The midline output issue (AND following JOIN - terrible message, btw) is standard fare for every stack-based boolean controller. Perhaps Koyo changed the implementation of Click, but every other Koyo controller ever sold uses this same exact approach, as did Texas Instrument before them.

I honestly don't see the attraction of big complicated rungs, and I certainly don't see the attraction of embedding sequence into flat ladder. It's visually overwhelming, hard to understand, and difficult to maintain...but...I'm a software developer, not a ladder developer, so your mileage may vary.

As I said, we know how to fix it. The truth is, the instruction to do so is already in the controller, but we spent a little time looking into it and concluded that it wasn't trivial in DmD. It affects at least three key areas that we don't touch without very good reason to do so. I honestly never considered this to be a be deal - it usually gets resolved with a little education - but maybe I am underestimating the impact of it.

If others would like to weigh in, I'd love to hear your thoughts. Is the inability of Do-more to do mid-line outputs a big deal?

[Controls Guy]

I guess my take is kind of analogous to b_carlton.

Is it annoying?  Absolutely.

Would I like it to change / get fixed (depending on perspective)?  Sure. I'd also like inline one-shots deeper than stack level 0.  I'd like n-dimensional arrays (wuth slicing syntax and math ops to boot)  and nested UDTs, too.

But DM does so many other things so well at such high performance with so much less effort than some others that there's no way I'm going to stop using them.  I use boatloads of them.  They're awesome.

[BobO]

One of the major considerations here at Host is where best to invest limited resources. We are starting to discuss the Son of Do-more, which would be a significant refactor of the engine, and a semi-clean sheet programming environment. Pretty much everything y'all want would happen. That will take some time though.

In the meantime, we will take a 2nd look at mid-lines. Not a hint of a promise there...we're just gonna look.