Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: mhw on April 09, 2013, 03:24:28 PM
-
I need someone to hold my hand as I do my first do-more project.
I am trying to have a tmr reset itself every time it's done bit comes on. I have the following line of code in "$Main": STRN T6.Done TMR T6 DLV10. Currently I have DLV10 set to 500. Viewing the tmr.done bit in trend view shows that it will be on sporadically. I have tried this in both sim and to an actual PLC with the same result. In the past I have done this same thing in DS5 without any problems.
-
Every 500 milliseconds(1/2 second) it is resetting the timer.
Right?
-
That should work just fine. The .Done bit will only be on for 1 scan...which in Do-more land is pretty quick. You won't see it in Trend view every time...
-
Every 500 milliseconds(1/2 second) it is resetting the timer.
Right?
Yes
You won't see it in Trend view every time...
That's disappointing, but good to know.
-
That's disappointing, but good to know.
What were you wanting it to do?
-
That's disappointing, but good to know.
What were you wanting it to do?
The disappointing part is that trend view will not capture a one scan event. What I described earlier is a test that I had set up to try and understand why what I am tring to do does not work.
What I am trying to do is to use a counter done bit to trigger a math calculation that uses the accumulated value from a tmr. This same done bit also resets the counter and the timer. Apparently the timer is reset before the math can grab the value. This is all logic that worked great in DS5.
-
The disappointing part is that trend view will not capture a one scan event. What I described earlier is a test that I had set up to try and understand why what I am tring to do does not work.
Sorry to disappoint. The Trend view is an async data client that just reads as fast as it can. It is not a scan to scan capture, although that it something that we would like to do in the future.
With typical scan times on the order of a few hundred micro seconds, Do-more is fast enough that gathering and managing scan-to-scan data is not an insignificant task.
What I am trying to do is to use a counter done bit to trigger a math calculation that uses the accumulated value from a tmr. This same done bit also resets the counter and the timer. Apparently the timer is reset before the math can grab the value. This is all logic that worked great in DS5.
Timer and counter logic in Do-more are virtually identical to DL implementations. Post your logic and we are happy to help you.
-
What I am trying to do is to use a counter done bit to trigger a math calculation that uses the accumulated value from a tmr. This same done bit also resets the counter and the timer. Apparently the timer is reset before the math can grab the value. This is all logic that worked great in DS5.
If the reset is before the MATH in the ladder(even if it is in the same rung) then your math will always read a zero.
Try placing the MATH before the timer reset on the rung
-
My mistake, of course.
In status view I was seeing .125 sec in the timer accumulator. So I thought I was using .125 in my math and assumed that we were doing floating point math. My math was 45/T1.acc=DLV0. This was giving me a result of 0. I started running down the wrong road when I did not see my math trigger showing in trend view. Thanks for the help.
-
Cool.
I think you'll like DMD when you get used to it!
-
Is there a way to rename a code block?
-
Is there a way to rename a code block?
Yes. From the memory config in the system configuration. Select the associated structure from the Heap Items list and edit it.
Because there are lots of possible things that can happen when memory blocks or heap items are updated, we force most of those changes to happen through the system configuration, since it understands all of the rules. It isn't the most obvious, but architecturally it is best.
-
Is there a way to rename a code block?
You can also do it from the Project Browser. Make sure you are in Edit mode (Ctrl+E), then right click on the code-block you want to rename and select Configure Code Block. That lets you rename a user code-block (but not system code-blocks).
-
Is there a way to rename a code block?
You can also do it from the Project Browser. Make sure you are in Edit mode (Ctrl+E), then right click on the code-block you want to rename and select Configure Code Block. That lets you rename a user code-block (but not system code-blocks).
Really? I was looking for that just yesterday and didn't see it. <sigh>
Ok...disregard what I said about architecture...
-
Is there a way to rename a code block?
You can also do it from the Project Browser. Make sure you are in Edit mode (Ctrl+E), then right click on the code-block you want to rename and select Configure Code Block. That lets you rename a user code-block (but not system code-blocks).
Ah...'Configure Code Block' is the issue. I was looking for 'Rename...'. Not suggesting we change anything, but I suspect most folks will miss that.
-
It's not too hard Bob... I managed to find it!
I've used it quite a bit actually. :)
-
[[/quote]
Ah...'Configure Code Block' is the issue. I was looking for 'Rename...'. Not suggesting we change anything, but I suspect most folks will miss that.
[/quote]
That was my excuse also.
Next question. When a timer is highlighted and I hit the spacebar it will pop the existing nickname in an editable view. This works great if I have one named "CONVEYOR1_DLY" and I copy/paste that timer and then create a new one with the name "CONVEYOR2_DLY". I am able to change the 1 to a 2 and then select the next available timer. Works great, kind of makes me like the name based programming. ;) However when I spacebar on a contact it will pop the native element. Is this a configuration option that I can change or just the way it is?
-
It's not too hard Bob... I managed to find it!
I've used it quite a bit actually. :)
It has been clearly established that you are not "most folks", so I have come to expect that you will wreck the curve for the rest of us. ;)
-
Next question. When a timer is highlighted and I hit the spacebar it will pop the existing nickname in an editable view. This works great if I have one named "CONVEYOR1_DLY" and I copy/paste that timer and then create a new one with the name "CONVEYOR2_DLY". I am able to change the 1 to a 2 and then select the next available timer. Works great, kind of makes me like the name based programming. ;) However when I spacebar on a contact it will pop the native element. Is this a configuration option that I can change or just the way it is?
Fun...the editor favors the nickname in a box, but favors the element in a contact. Thoughts Mark?
There is a workaround, but it may leave you with separation anxiety for conventional element names. It is the only mode I ever run in, and is affectionately known as 'Bob mode' here at Host. Go into Options and turn off 'Elements'. With elements off and nicknames on, the display code will use a nickname if one is configured, and then will display the raw element only if there is no nickname. Truth is that once I have named something, I couldn't care less whether it is C143...that info is noise to me. True 'Bob mode' is running with just nicknames...no elements, extra info, or descriptions...but that may be too lean for some.
-
It's not too hard Bob... I managed to find it!
I've used it quite a bit actually. :)
It has been clearly established that you are not "most folks", so I have come to expect that you will wreck the curve for the rest of us. ;)
Ummmmm. Oh. :-\
-
It's not too hard Bob... I managed to find it!
I've used it quite a bit actually. :)
It has been clearly established that you are not "most folks", so I have come to expect that you will wreck the curve for the rest of us. ;)
Ummmmm. Oh. :-\
That was actually a very high compliment, if that wasn't clear.
-
It's not too hard Bob... I managed to find it!
I've used it quite a bit actually. :)
It has been clearly established that you are not "most folks", so I have come to expect that you will wreck the curve for the rest of us. ;)
Ummmmm. Oh. :-\
That was actually a very high compliment, if that wasn't clear.
Why thank you! (I think I picked the wrong face). I was trying to convey more the feeing of being considered a nerd ;)
-
The Bob mode has at least one disadvantage. If I just created a timer with the name "CONVEYOR1_MT_TMR" and on the next line I want to use it's done bit. It takes more key strokes to access than looking up and then typing "T6". Also if I forget the syntax for the shorthand that I am using. I could accidentantly turn on a physical output instead of a control bit. Nice to have the cross reference.
The positive of the Bob mode is that it declutters the screen.
-
Fun...the editor favors the nickname in a box, but favors the element in a contact. Thoughts Mark?
It's definitely a Bob-mode thing for now. That's a hold-over from DirectSOFT, but we can tweak contacts/coils to behave like Boxes (prefer Nicknames over Elements when editing). However, that may hinder people who DO want to see elements when editing - they have no option other than to COMPLETELY turn OFF NICKNAMES.
Not sure what the best answer is. Maybe add an option when both elements and nicknames are enabled, to prefer nicknames or prefer elements when editing? Prefer one over the other when only 1 is displayed (edit and display)?
The current behavior is that when BOTH are enabled in DISPLAY of boxes (not Edit), Designer displays BOTH for the FIRST parameter, but prefers nicknames over elements for all other parameters. For multiple input boxes, it displays BOTH for the first (number of input legs) parameters (e.g. UDC displays both for the first 3 parms). The editing behavior is different between contacts/coils and boxes. Minimally, those need to be consistent (whatever we conclude), but I also like options when it's not obvious.
-
Then I guess the 'PLCNut' mode will be when things break by being pressed to those far corners of the envelope.
-
Then I guess the 'PLCNut' mode will be when things break by being pressed to those far corners of the envelope.
I'm requesting plastic corner protectors to go in the envelope.
;D
-
Then I guess the 'PLCNut' mode will be when things break by being pressed to those far corners of the envelope.
Mr. Nut has definitely pushed the boundaries, and by doing so has found more than his share of problems. But I will also say that in doing so he has confirmed my faith in our customers, and has validated so much of what we did in Do-more. So very many times, the folks that drive our perception of the typical skillset of our users are the ones that tend to lack experience...since as you would expect, the experts by and large don't need our help. This leads to a somewhat skewed view of our user base, which has led to countless debates among the various groups at Host and ADC as to what features should or should not be in the controller. As developers we tend to favor putting things in the product we would want to use, the marketing folks are usually more inclined to agree with us...just because more features are great for advertising, but the support guys shudder at the lengths of stout rope that we tend to put in our products. So when I see customers using some of those power features to do very cool things, it confirms that we were right to include them, and validates my belief that there are some pretty sharp cookies out there. ;)
-
And let me be very clear about my comments in the previous post...particularly because this thread was (prior to being hijacked) a first time Do-more user. We *love* to educate customers on how to use our products...regardless of level of experience. Never, ever, think that your questions are a bother to us. Quite the contrary, your questions help us understand how to build a better product.
ADC has done an amazing job of making automation products approachable to a wide audience. Of course 'wide audience' equals 'vastly different experience levels'. Given that the price of entry to the PLC club is about $69, it is inevitable that Christmas lights and train sets will be control targets. Just try to imagine the conversation between me and the support guy responsible for helping twinkle lights bring Christmas cheer to a family in Boise:
<Me (breathless from excitement)> "...and you can use the TCPLISTEN instruction to run a program block when a remote TCP device establishes a connection to the TcpServer device. You can then implement a full custom protocol using STREAMIN and STREAMOUT instructions in a Stage based sequence. It's powerful enough that you could even implement a web server with our protocol creation primitives. Freakin' cool, huh?!?"
<Christmas Cheer Tech (with face now pale)> "Uh...yeah." :facepalm:
Then imagine how the support realities influence product development. Or put another way, how do we build a product that both Sheldon and Penny will use? ;)
PS. If you happen to live in Boise and are using a PLC to control your Christmas lights, you *rock* dude!! ;D
-
Just to add to the hi-jack:
I gave some sound sensors to a fellow at work who intends to control his Christmas lights using a PLC monitoring sound/vibration :D
-
I have been programming in stages for years now. My little programming mind now likes to think in stage. But I really like the way the programs in DMD easily distinguish sections of code in a tree view. Can stages, in the old DS5, and programs, in DMD, be considered functionally the same? Obviously there is not a JMP instruction, but a run followed by an exit appears to do the same. Can you think of any differences in operation that I should be aware of?
-
Good question and widely misunderstood.
Stages are consistently misused in DL, partially because there is not another modularization mechanism, and partially due to ignorance. First and most importantly...Stage is Koyo's version of SFC. It is a sequencing mechanism. When used as a sequencing mechanism, it is a very cool thing. Because there is no way to break code up into manageable chunks in DL, folks tend to use Stage for modularization *and* sequencing. Couple this with the fact there is only one pool of stage bits, stuff gets messy...customers get confused...and many people have developed an allergy to Stage.
In Do-more we introduced Program and Task blocks to handle modularization...but we also recognized that we still needed a sequencing mechanism as well. So we added Stage to Program blocks. So no...programs are not like stages, in fact, programs can contain stages. Can you modularize with Stage? Yes, but they are optimized for sequencing. Can you sequence with Programs? Yes, but they are optimized for modularization.
Here is the best way to think about it:
* Use Program and Task blocks to break up code into modular chunks.
* If the lifespan of the chunk is controlled by the thing enabling it, use a Task. An example of this would be if you wanted to put all of the code associated with alarms into its own module, and then turn them on or off from $Main, you would use a task. You can also use Tasks to do operations that don't need to happen continuously or operations that use loops to do time consuming things.
* If the lifespan of the chunk is controlled by the chunk itself, use a program. An example of this would be a status report that gets sent out every Friday. From $Main you would RUN the report program, which would then gather then data, construct the report, and send it out. Upon completion it would EXIT.
* If a program needs to step through a sequence as part of performing its function, you would use stages in that program. The status report of the previous example would likely use stages...or anything that is described as a sequence of operations. It is super easy to create custom communications in Do-more using stages. I actually create entire protocol handlers as standalone programs...and it is easier in Do-more than it is in C++ in a PC. By far.
Not sure if this helped or hurt...but we are happy to help you better understand.