Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: RBPLC on October 18, 2019, 05:55:53 PM
-
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?
-
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 (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.
-
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?
-
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.
-
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?
-
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.
-
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.
-
So am I to understand that the preferred method for dealing with this type of logic is to stage it?
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
I'd like n-dimensional arrays (wuth slicing syntax and math ops to boot) and nested UDTs, too.
We'll definitely do n-dimension and nested UDTs. In evaluating the engine implementation, we realized that the memory math required to do arrays of structs of arrays of structs, etc, n-dimension arrays, and simple parameter math, was all basically the same. We have some pretty good ideas and are quite excited about the potential. Just gotta get the BRX analog modules rolled out and then we're going start investigating more deeply.
-
To me lack of "mid-line outputs" may not necessarily be a big deal as I better understand how to optimally use the software. It just threw me off because I was initially trying to copy ladder code from Mitsubishi verbatim into DMD. I agree that long ladder runs can get overwhelming and confusing to read. In this particular program there are several instances of long runs that get hard to follow but I didn't write the initial program. I was going to initially copy everything verbatim and then re-work it where it made sense. It's just my inexperience with DMD and lack of seeing this issue before that was throwing me for a loop because I assumed that I would have no problem copying the program verbatim. When I went to compile it and got error messages or broken code I thought I was missing something. It would definitely be nice to have the ability to do what I'm trying to do but may not be a showstopper. As mentioned, I would also like to see 2-D arrays, implicit EIP and websever and a fix to the issue discussed in this thread. From my experience, these are some of the very few areas in which DMD falls short in comparison to Productivity Suite software (of which most of my other experience comes from). I know you guys are actively working on implicit EIP and webserver.
-
I agree we need 2D and 3D arrays, Implicit E/IP. These are the biggest issues for me. We use 3D arrays and manage them with OPC and excel for CIP (clean in place) systems in the food and beverage industry and all of the drives, flow meters, conductivity meters, etc. use implicit ethernet/ip messaging. As said in another post without these things it will not keep me from using the DoMore but we will have to use other platforms (AB, Siemens, GE/IP) for these types of projects.
JW
-
We'll definitely do n-dimension and nested UDTs. In evaluating the engine implementation, we realized that the memory math required to do arrays of structs of arrays of structs, etc, n-dimension arrays, and simple parameter math, was all basically the same.
Awesome, all those things will make my programming life easier and lead to cleaner programs. Thank you in advance!
-
So...I've tried to implement stage programming for the example given previously and for this application stage is not the answer. When looking at the code, there is an element that could be staged but it is not ideal. Stage is meant to handle sequential actions. The example I posted is more a machine safety circuit with multiple parts of the machine coming on at the same time, not sequentially, and staying on unless a fault condition is seen. Even with stage, additional status bits and replication of code has to be done. I vote for fixing the mid-line output issue.