Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: BobO on February 08, 2013, 03:21:04 PM
-
Do-more has been shipping for 5 months and many of you have now tried it. Please help us improve it. Rate it, and then add a message giving us a sense of how you see yourself using it, or not using it, in the future. If there are specific areas that are standing in the way of using it in the future, please explain how we can do a better job. We are actively working on new platforms, we plan to be selling this for a long time, and we genuinely want your comments...good, bad, or otherwise.
-
Just happened to be working in the Do-More Designer on my first Do-More project when the announcement e-mail popped up so this is very timely.
I would have to say that I am overall very impressed with the system - there is a learning curve as with any new system but I'm finding a number of things that are awkward or hard to do with a DL205 (indexing into a table of values comes to mind) much easier to configure and work with. I love the easy modularity of the programs/tasks though I'm afraid my project will end up being a huge collection of small bits glued together with RUN/ENTASK commands. I worry about maintainability of this, particularly if I have to pass the project on to a colleague but it's still not very large so we'll see how the search / navigation features operate once it gets a bit bigger.
Getting it to talk to a C-More screen wasn't as seamless as doing so with a DirectLogic (when trying to use K-Sequence) but the transparent Modbus slave setup is really nice so I've switched to that.
I will definitely use these in place of DL205s going forward. There's really no downside to having a more powerful PLC with a built in Ethernet port.
As far as a wishlist, if you can get this controller in a DL06 form factor with an Ethernet port, I would never buy a DirectLogic PLC ever again. The only other thing that I've found myself wanting is if the built-in Ethernet port could act as an ERM.
So far, a very positive experience.
Jacob
-
I would have to say that I am overall very impressed with the system - there is a learning curve as with any new system but I'm finding a number of things that are awkward or hard to do with a DL205 (indexing into a table of values comes to mind) much easier to configure and work with. I love the easy modularity of the programs/tasks though I'm afraid my project will end up being a huge collection of small bits glued together with RUN/ENTASK commands. I worry about maintainability of this, particularly if I have to pass the project on to a colleague but it's still not very large so we'll see how the search / navigation features operate once it gets a bit bigger.
Are your tasks and programs standalone behaviors, or are you sequencing them? If you are using them for sequence, I would look at using stages. If they are standalone, and you find it cumbersome to manage, it would be great to brainstorm some improvements to the project manager. We are definitely open to improvements.
Getting it to talk to a C-More screen wasn't as seamless as doing so with a DirectLogic (when trying to use K-Sequence) but the transparent Modbus slave setup is really nice so I've switched to that.
I understand the issue. Wish there were a better answer, but hopefully as ADC gets Do-more native support across the line it will get easier.
I will definitely use these in place of DL205s going forward. There's really no downside to having a more powerful PLC with a built in Ethernet port.
That's what we hope to hear more of!
As far as a wishlist, if you can get this controller in a DL06 form factor with an Ethernet port, I would never buy a DirectLogic PLC ever again.
I think you will like what we have coming down the pipe. Can't give details yet, but we are definitely answering the need.
The only other thing that I've found myself wanting is if the built-in Ethernet port could act as an ERM.
That feature will be DmD 1.1. It's already running in the lab, and is very nice. Not just an ERM, but fully native Ethernet remote I/O.
-
I LOVE IT!!!!! I have completed one major project with it and, even with the learning-curve, I was able to translate a massive 260-based program to the DoMore fairly easily and it came up functional quite well. I especially love the flexibility with the Modbus communications: I had to talk to two Sure servos AND five recitifiers, out two different ports! I actually had to simplify my implementation as I no longer needed the time-sharing code I had written sequence port access for the 260.
I would write for the DoMore exclusively but it doesn't always apply. CLICKs are perfect for the simpler jobs, like an 05, but the 05 can have a CTRIO. I don't miss the CTRIO in a CLICK at all. It DOES need a bit more analog though.
The 06 would be the only other platform I would port the DoMore to. BUT, before porting it, add ERM capability to the DoMore in the 205 series, or give me back the CM/EM.
I wanted to use the DoMore for a proposed project I am working on now, but the DoMore doesn't have the memory or data-logging to a USB memory stick, so I will use the PRO3000. (Which is NOT a step down! The PRO3000 is awsome too!)
The 305 is a dinosaur and the 405 SHOULD be a dinosaur. I will not be sorry to see them fade away into a much desrved retirment. They held their own but it is time for smaller and faster!
-
That feature will be DmD 1.1. It's already running in the lab, and is very nice. Not just an ERM, but fully native Ethernet remote I/O.
Could you explain how you're differentiating between the two? I thought ERM/EBC WAS the native Ethernet RIO system for DL PLC's.
-
That feature will be DmD 1.1. It's already running in the lab, and is very nice. Not just an ERM, but fully native Ethernet remote I/O.
Could you explain how you're differentiating between the two? I thought ERM/EBC WAS the native Ethernet RIO system for DL PLC's.
ERM just paints memory and currently offers no Do-more based configuration, visibility into base contents, or support for modules like CTRIO. The onboard function is essentially indistinguishable from local I/O, is configured via the system config, and has complete native support for all CTRIO structures and instructions.
-
Ok...over 40 views, but only 3 votes in my poll. If you have used Do-more, don't be afraid to vote!
-
ERM just paints memory and currently offers no Do-more based configuration, visibility into base contents, or support for modules like CTRIO. The onboard function is essentially indistinguishable from local I/O, is configured via the system config, and has complete native support for all CTRIO structures and instructions.
Ah OK, so by "native" you mean "Do-More native", not "ADC native". Sound like some awesome capability! So how will the new capability be delivered? New EBC firmware? A new EBC specifically for use with DM CPU's?
I haven't had a project in almost a year where I got to pick the controller :( but have a couple machine-builder customers I've told I want to use Do-More as the standard controller from now on, and they're OK with that, but haven't built any new equipment or THEY have had the controller specced to them. Shouldn't be too much longer though -- so I keep telling myself!
-
Oh, and I've also never liked the options for what to do on an EBC base on loss of comms.
Last state is risky, but all-off won't work with a lot of continuous processes. You lose comms for a second, everything turns off, crashes the process, then the comms come back, but it's too late. You can't even do online edits, because it interrupts comms long enough to burp the remote racks. (I realize the specific issue of online edits should be alleviated in Do-More due to the hot cutover runtime edits).
I vote for a third setting that keeps last state for some user definable time, like say 5 seconds, followed by all off if comms aren't restored during the delay.
-
I love my do-more plc!
I chose it (and other AD products) for my long term home automation project mainly based on cost.
I am connected with the designer software from a virtual machine on my mac via ethernet.
The project has some digital and analogue io, and hmi and remote access. So the do more is perfect.
The resources and help files are far superior to Mitsubishi Q series. In fact the whole learning curve has been more enjoyable than Mitsi.
Id like a keyboard shortcut for toggling a force on/off. ie Mitsi has shift + enter.
Well done! it is comparable to much more expensive systems.
-
Ah OK, so by "native" you mean "Do-More native", not "ADC native". Sound like some awesome capability! So how will the new capability be delivered? New EBC firmware? A new EBC specifically for use with DM CPU's?
There is new EBC100 firmware, but the key is the Do-more CPU itself. We've tweaked a few things in the EBC, but mostly to make the CPU's job easier...no real changes in EBC100 functionality. It's already seamless enough that I can update CTRIO firmware while it is installed in the remote base...no small feat. I think folks will like it.
-
There is new EBC100 firmware, but the key is the Do-more CPU itself. We've tweaked a few things in the EBC, but mostly to make the CPU's job easier...no real changes in EBC100 functionality. It's already seamless enough that I can update CTRIO firmware while it is installed in the remote base...no small feat. I think folks will like it.
No small feat at all. Very impressive! 8)
-
Oh, and I've also never liked the options for what to do on an EBC base on loss of comms.
Last state is risky, but all-off won't work with a lot of continuous processes. You lose comms for a second, everything turns off, crashes the process, then the comms come back, but it's too late. You can't even do online edits, because it interrupts comms long enough to burp the remote racks. (I realize the specific issue of online edits should be alleviated in Do-More due to the hot cutover runtime edits).
I vote for a third setting that keeps last state for some user definable time, like say 5 seconds, followed by all off if comms aren't restored during the delay.
Hmmm...lots to ponder. We are treating a remote failure with the same respect as a local failure...meaning: fatal. The key would be in how we define failure. I think we could create the situation you are describing with the current implementation. The EBC's link monitor time can be set to whatever you choose...so how long we go missing before it shuts down is one question. The other question is how long things must fail before the CPU logs him out and goes fatal...this too is configurable. Between timeouts and/or retries at both ends, I think you can do what you are wanting.
-
I love my do-more plc!
I chose it (and other AD products) for my long term home automation project mainly based on cost.
I am connected with the designer software from a virtual machine on my mac via ethernet.
The project has some digital and analogue io, and hmi and remote access. So the do more is perfect.
The resources and help files are far superior to Mitsubishi Q series. In fact the whole learning curve has been more enjoyable than Mitsi.
Id like a keyboard shortcut for toggling a force on/off. ie Mitsi has shift + enter.
Well done! it is comparable to much more expensive systems.
Thanks for the feedback, and very glad to hear that Do-more is working well for you! We've had the request for the hot-keyed toggle before. Other than paranoid concerns about safety, I don't see a problem with it. I think that you see features like this in Japanese brands more often because they have a significantly less litigious environment than we do. Unfortunately, the reality of doing business in the US is that you are far better off to annoy people while covering your tail. ::)
-
I think that you see features like this in Japanese brands more often because they have a significantly less litigious environment than we do. Unfortunately, the reality of doing business in the US is that you are far better off to annoy people while covering your tail. ::)
Actually, the cleanest implementation I've seen is AB, at least for bits. Right click on a contact, and Force On, Force Off, and Remove Force are in the context menu. Love it. It's been there for decades and they haven't got sued for it that I know of. Course AB's legal department may be slightly larger than Hosts! :D
-
Actually, the cleanest implementation I've seen is AB, at least for bits. Right click on a contact, and Force On, Force Off, and Remove Force are in the context menu. Love it. It's been there for decades and they haven't got sued for it that I know of. Course AB's legal department may be slightly larger than Hosts! :D
I'm less allergic to that because it requires two clicks. It would actually be very easy to do it that way, at least for bits. In the interest of keeping the context menu smaller, I might be inclined to put the force options you describe on a 'Force' sub-menu. It would still be a single click on the menu, but you would have to mean it if you went to a second menu layer. In addition to 'Force On', 'Force Off', and 'Unforce', we could also do a 'Toggle State', which would be smart enough to toggle both a forced and unforced value.
-
I'm less allergic to that because it requires two clicks. It would actually be very easy to do it that way, at least for bits. In the interest of keeping the context menu smaller, I might be inclined to put the force options you describe on a 'Force' sub-menu. It would still be a single click on the menu, but you would have to mean it if you went to a second menu layer. In addition to 'Force On', 'Force Off', and 'Unforce', we could also do a 'Toggle State', which would be smart enough to toggle both a forced and unforced value.
Oh yeah, I don't think I'd want a UI where you could force with a single click. I'm sure the disasters would commence just about immediately. It's not the end of the world, but I'm not crazy about the force sub-menu, cause you're now back up to three clicks. Oh, and toggle without forcing is also on AB's context menu (and there's a hotkey as well).
Anyway, even at three clicks it's way better than the gauntlet of agony you have to endure in DirectSoft to convince it you actually want to force something in a DL Classic CPU.
-
Anyway, even at three clicks it's way better than the gauntlet of agony you have to endure in DirectSoft to convince it you actually want to force something in a DL Classic CPU.
Actually it would only require 2 clicks. A one second hover on the sub-menu opens it.
And I think you can change a value in DSP with a double-click followed by a single click. It ain't that hard. Unless you are referring to the override feature (Koyo's force-esque feature)...in which case, yeah, that's a pain.
-
And I think you can change a value in DSP with a double-click followed by a single click. It ain't that hard. Unless you are referring to the override feature (Koyo's force-esque feature)...in which case, yeah, that's a pain.
I was talking about the overrides. Yeah, it reminded me of the Preventer of Information Technology in Dilbert. Like they dinged the salary of the guy who wrote the UI every time someone successfully managed to force something, so he designed it to be as convoluted and painful as possible.
Even the set bit dialog feels cumbersome. Not sure why, like you said, it's just two actions.
-
And to me, while it's not technically a click, a hover is just as bad. You have to focus your attention three times and make three motions with your hand, so it's three actions, even if you don't have to click all three times.
But -- like I said, even at three actions it's far superior to the overrides in DS.
-
I haven't had a chance to go for a full blown project yet, but I definitely like the environment. I would like to see the ability to have local expansion I/O using D2-EM & D2-CM expansion. 1-2 Additional racks would be great.
On another note, when I insert an ERM in the I/O rack, it gives a choice for H2-ERM100, in addition to H2-ERM and H2-ERM-F. I cannot find the H2-ERM100 at ADC. Is this coming soon, and, what are the chances of seeing H4-EBC100's. Do-More will be great as an upgrade controller for legacy systems where we've supplied both D4-450 & D2-260 CPU's to be replaced by the existing H2-EBC100 and a "hopeful" H4-EBC100.
Keep up the good work, keep the faith.
I appreciate your boldness to proclaim the Source of all blessing!
-
I would like to see the ability to have local expansion I/O using D2-EM & D2-CM expansion. 1-2 Additional racks would be great.
We were concerned about the performance limitations and chose not to support the EM/CM. We are currently developing a native Ethernet remote master function on the DM1E. It will be part of the upcoming 1.1 release, hopefully soon. Unlike the EM/CM, the Ethernet remote I/O function will be very high performance and will fully support the CTRIO. It will also allow mixing I/O platforms...any EBC100 variant will work with it.
On another note, when I insert an ERM in the I/O rack, it gives a choice for H2-ERM100, in addition to H2-ERM and H2-ERM-F. I cannot find the H2-ERM100 at ADC. Is this coming soon, and, what are the chances of seeing H4-EBC100's. Do-More will be great as an upgrade controller for legacy systems where we've supplied both D4-450 & D2-260 CPU's to be replaced by the existing H2-EBC100 and a "hopeful" H4-EBC100.
We are definitely doing an H2-ERM100, although the 405 is a little harder to say. We have talked about doing an H4-EBC100 and an H4-DM1E. We'll see.
I appreciate your boldness to proclaim the Source of all blessing!
It defines us. Of course there needs to be a balance in business and we want to be known for the quality of our work, but there is no doubt in my mind that our creativity comes from the Master Engineer.
-
I appreciate your boldness to proclaim the Source of all blessing!
It defines us. Of course there needs to be a balance in business and we want to be known for the quality of our work, but there is no doubt in my mind that our creativity comes from the Master Engineer.
One of the reasons I love to use Host's products! Quality, Real people, Like-minded boldness for old-fashioned Faith! :)
PC is killing us!
-
I voted for the only PLC I would ever use.
I was a little bit intimidated by the idea of learning a new control environment... until I tried it... and it has been a GREAT changeover! I dread opening DS5, although DMD is so similar, DS5 seems clunky already. The Programs/Tasks make for a much more organized system, and I really like the Project Browser with the option for viewing which program, task, or stage is active at any time in one small view. Also the User defined Structures and the ability to adjust memory ranges is super! Another great tool is the DMLogger, it is super when designing/tweaking a custom protocol, and seeing what the PLC is actually seeing, simple to use to.. just turn it on :) .
Thanks for the great product!
-
We build machines and systems for other people, so we are told what hardware to use on some of them. (Some customers only have AB or GE or Siemens, etc. in the plant and will not except anything else) If we have a choice or input into the hardware we normally spec AD. The hardest sell is the people that only know one system, it's like the old saying "if someone is good with a hammer everything looks like a nail". I have had quite a few hard line AB and GE guys impressed with AD when we show them how it works, and if they have to pay for the hardware/software even more so. As for the DoMore I think it is a huge step in the right direction, there is a little learning curve (for us old guys) but I really like the system. I have been programming AD for almost 20 years, it's hard to forget octal based numbering and BCD math.(ha,ha, not really) Now you need to get the 06 with the same capability with a built in Ethernet connection. Over all we use about 60% AD hardware,(With the DoMore we hope to increse that percentage) of that about ~75% are 205 systems, (we will use DoMore from now on) ~20% are 06 systems, (we need a DoMore system for this) ~4% PAC's and ~1% or less 05's and clicks(These systems are stand alone and small I would make this the lowest on the DoMore change over timeline) We dont use the 305 or 405 systems.
Thanks for a very good product at a very good price.
JW
-
Any firmware updates available for the older EBCs so that they will play with either the Built-in ethernet remote master or the eventually to be released DMcompliant ERM100 remote master? I have a fully populated 3 rack system (27 slots)... so an ERM in the base...and an EBC in each of the racks.
All of that said..it's the serial interfaces that have my attention at the moment.... have some parts on order.... I'll let folks know what I've found to do with it eventually (I'm not good....but I sure am slow).
Peter
-
Any firmware updates available for the older EBCs so that they will play with either the Built-in ethernet remote master or the eventually to be released DMcompliant ERM100 remote master? I have a fully populated 3 rack system (27 slots)... so an ERM in the base...and an EBC in each of the racks.
The current plan is that the onboard Ethernet master will work only with EBC100 variants running Do-more aware firmware. There are a couple of reasons for this, but it mostly related to the fact that we added several new features to support the onboard master...and the old EBCs were full. The new ERM100 will support all EBCs, and unlike the original ERM, is Do-more aware and writes to Do-more memories rather than DL guest memory.
-
Fully understand... have to cut bait sometimes... DL205 platform has had amazing longevity... can't drag all of the bits n' pieces into the brave new world.
Will there be firmware updates for existing EBC100s? (I have one of those kicking around...but didn't want to mix it with my existing ERM/EBC setup)..
-
Fully understand... have to cut bait sometimes... DL205 platform has had amazing longevity... can't drag all of the bits n' pieces into the brave new world.
Will there be firmware updates for existing EBC100s? (I have one of those kicking around...but didn't want to mix it with my existing ERM/EBC setup)..
There will definitely be firmware updates for existing EBC100s!
-
So from the point of view of the Do-More, will ERM100's with remote EBC's be a transparent I/O expansion like the native port, or will it still map to memory like current ERM/EBC systems?
-
So from the point of view of the Do-More, will ERM100's with remote EBC's be a transparent I/O expansion like the native port, or will it still map to memory like current ERM/EBC systems?
This is an ongoing discussion. It a minimum, the ERM100 will paint native Do-more memories X, Y, WX, and WY...so no more dealing with DLX, DLY, etc. As to whether we will try to do everything with the ERM100 that we are doing with the onboard master, jury is out. Some of what we are doing might be painful due to the backplane being slower than direct access to the Ethernet port. Haven't fully explored the engineering realities, but it may simply not be feasible.
There is another aspect that we are considering though. Because we are using the same rules on the onboard master as the local base master, it isn't really conducive to more data-centric mastering. What does that mean? Some apps use remote bases for optional data acquisition and the I/O isn't really I/O in the local base sense, it's more of a remote data source that happens to use PLC I/O. I am not making any provisions for a more relaxed data-centric acquisition in the onboard master. Apps like that are easily managed by using Modbus/TCP instructions to talk to the I/O rather than using the Remote I/O master...but some folks would rather have a module handle the comm and eliminate the programming requirement. And to that end, I am somewhat inclined to leave the ERM100 like it is, just with the addition of native memory access.
It seems like a subtle point perhaps, but I have much stronger opinions about the way native I/O should work, and leaving the ERM100 working as a memory painting co-processor, while treating the onboard Ethernet master as local I/O that happens to have a cable connecting it, gives us the ability to do both. Clear as mud?
-
This is an ongoing discussion. It a minimum, the ERM100 will paint native Do-more memories X, Y, WX, and WY...so no more dealing with DLX, DLY, etc. As to whether we will try to do everything with the ERM100 that we are doing with the onboard master, jury is out. Some of what we are doing might be painful due to the backplane being slower than direct access to the Ethernet port. Haven't fully explored the engineering realities, but it may simply not be feasible.
There is another aspect that we are considering though. Because we are using the same rules on the onboard master as the local base master, it isn't really conducive to more data-centric mastering. What does that mean? Some apps use remote bases for optional data acquisition and the I/O isn't really I/O in the local base sense, it's more of a remote data source that happens to use PLC I/O. I am not making any provisions for a more relaxed data-centric acquisition in the onboard master. Apps like that are easily managed by using Modbus/TCP instructions to talk to the I/O rather than using the Remote I/O master...but some folks would rather have a module handle the comm and eliminate the programming requirement. And to that end, I am somewhat inclined to leave the ERM100 like it is, just with the addition of native memory access.
It seems like a subtle point perhaps, but I have much stronger opinions about the way native I/O should work, and leaving the ERM100 working as a memory painting co-processor, while treating the onboard Ethernet master as local I/O that happens to have a cable connecting it, gives us the ability to do both. Clear as mud?
Nope. Makes perfect sense. With the internal overhead and interlocking, do you expect the on-board port be adequate for simultaneous remote I/O mastering and HMI slave, particularly a Modbus slave? It shouldn't be a problem bandwidth-wise, but what about indirect bandwidth limitations due to a max number of transactions per scan? (Course blinding fast scans tend to make that issue go away too!) :)
-
Nope. Makes perfect sense. With the internal overhead and interlocking, do you expect the on-board port be adequate for simultaneous remote I/O mastering and HMI slave, particularly a Modbus slave? It shouldn't be a problem bandwidth-wise, but what about indirect bandwidth limitations due to a max number of transactions per scan? (Course blinding fast scans tend to make that issue go away too!) :)
I was initially afraid of the implications of running both Ethernet remote I/O and HMI type stuff at the same time, and strongly considered making you choose one or the other. After playing with it, while simultaneously considering how hard in practice it would be to limit it, I am inclined to leave it available with the suitable caveat emptor. The truth is that some users will mess it up no matter how hard I try to prevent it, and the sharp ones that listen, understand, evaluate, and then make their own call, can easily determine whether the system is practical. So, the official line will be that if you use it for I/O, and the I/O performance is critical, then please put the I/O on an isolated network and don't use the Ethernet port for anything else. If you can tolerate a little more flexibility in I/O data delivery, bump up the retries and have at it. The default is 4 retries and 100ms timeout.
I've had the Ethernet remote master on the simulator running on my PC on the office network for several days at a time with retries but no failures. That's to two EBC100s with CTRIOs installed in both systems, one a 205 and the other Terminator. There is all manner of control killing unholiness flying around the enterprise network, so a reasonably well-limited control network should be very clean by comparison.
-
Yeah, I never put processors on the main plant network. Maybe on a multi-machine network with surrounding machines, and the HMI PC's are usually on the plant network via a second adapter, but no connection directly from the PLC network to the plant. So yeah, much cleaner traffic-wise than your test case.
Can you do a primer in the internal mechanics of Do-More native Ethernet remote I/O, as well as a refresher on how Modbus comms are handled, particularly when the PLC is the server/slave? So we can get some idea of potential total throughput, the impact of scan time, and we can quantify, at least roughly, when we can share between an HMI and RIO?
Could you set a polling time for the remote, like 50ms or so (I realize this is pretty close to your suggestion to set the timeout and retry values)?
Thanks!
-
I hadn't planned on putting a poll rate on the I/O, although it would be pretty easy to do. I would think that should be a standard thing in HMIs, though, given that for human interaction anything faster than about 50ms is overkill.
For planning purposes, think in terms of packets received per scan. It is completely arbitrary, but currently within one scan I'll accept 16 packets unconditionally, then the next 16 are time regulated. At 32, within a single scan, I shut off the interrupt until next scan. The time regulation I mentioned is to allow up to 16 additional packets to come in if the scan is long, but not to exceed a certain number of packets per unit of time. Packets that exceed that frequency are tossed on the floor. The whole thing sounds rather Rube Goldberg, but the goal is to handle normal packet traffic, but block out packet storms...malicious or otherwise. It works quite well.
I'd think you'd have to be pretty hard on the system for 32 inbound packets per scan to be a meaningful limitation. Of course that will affect the scan time accordingly, but fast enough is, well, fast enough. It's impossible for me to know what is fast enough for your app...so I won't pass judgement.
With most industrial protocols, it's a packet out and a packet back. TCP introduces a wrinkle in that the are additional acknowledgments at the TCP level that have nothing to do with the actual protocol...definitely not as efficient as UDP. I still think that for reasonable systems, neither bandwidth nor packet counts should be a problem. Somebody will break it though...there are folks that could break an anvil. ;)
-
So define "packet" --
Would one Modbus write with 250 or so bytes be a packet?
How do RIO comms resolve to packets?
-
A packet is the basic unit of Ethernet communications...a data frame. I believe the maximum size of a standard Ethernet packet is 1536 bytes, and normally the minimum is 64. Virtually everything that happens in Host's world happens with a single sent and received packet. A single remote I/O transaction is one outbound packet containing the output state to be written, and an ack/response with the input state just read. A Modbus comm is generally one and out back, although as I suggested previously the TCP layer will sometimes throw other junk in there. I'm not a fan of TCP. Modbus/UDP would have made far better sense, but the fine fellows at Modicon thought otherwise. We used to debate it at trade shows back when Ethernet on the factory floor was just us crazies, but they were Modicon and I was (and remain) nobody.
-
So logistically you can do 16-32 bidirectional transactions per scan, where one transaction could be a Modbus request and response or one cycle of data exchange with one remote rack?
IOW, available bandwidth will be the limiting factor so long as you don't exceed 16-32 round trip transactions per scan??
If so, the app that can overwhelm that will be pretty intense indeed.
How about programming comms? What kind of bandwidth does that usually take, and how many packets per second would be typical for a programming session with status?
And now....for something completely different....do you happen to know if Sixnet is planning to do any switches with more than one fiber port, IOW a fiber switch? All ADC offers are media converters (one copper <--> one fiber) or copper switches with a single fiber port. That doesn't work well if all your I/O is far enough apart to want fiber to all the racks, or if you have racks in clusters that can be done in copper, because if you have more than one remote rack or cluster, you'll still need a ring or star in fiber for the long runs.
-
So you can do 16 bidirectional transactions per scan logistically, where one transaction could be a Modbus request and response or one cycle of data exchange with one remote rack?
Actually it's up to 32. It's just that after the first 16, I start pacing them to prevent packet storms killing my logic. Of course reality is that stuff is generally slow enough that a single remote I/O cycle (per slave) is an outbound packet and the result is a couple of milliseconds out. For planning purposes you would treat it the way you are doing, but things really don't happen so tight as to be a problem.
How about programming comms? What kind of bandwidth does that usually take, and how many packets per second would be typical for a programming session with status?
DmD is half-duplex. One comm per programming session at a time. A hundred per second would be pushing it.
And now....for something completely different....do you happen to know if Sixnet is planning to do any switches with more than one fiber port, IOW a fiber switch? All ADC offers are media converters (one copper <--> one fiber) or copper switches with a single fiber port. That doesn't work well if all your I/O is far enough apart to want fiber to all the racks, or if you have racks in clusters that can be done in copper, because if you have more than one remote rack or cluster, you'll still need a ring or star in fiber for the long runs.
No clue.
-
Cool, that sounds like in most cases you can do both and not worry about it.
On the switches, yes Sixnet does have ones with two fiber ports, even in the same family (light duty industrial) ADC sells as Stride, but those particular ones aren't in ADC's lineup (yet).
-
I guess it is appropriate to this topic...Host won a Control Engineering 2013 Engineers' Choice Award for Do-more! Thank you to everyone who voted for us!
Here's the link for anyone interested: http://www.controleng.com/events-and-awards/engineers-choice-awards/2013/winners.html (http://www.controleng.com/events-and-awards/engineers-choice-awards/2013/winners.html)
-
I have several of them out at this point and besides the learning curve all are performing well. Points to consider:
extensive use of tasks in my programming structure causes Comm fault when I view "all status"
(won't ever click that one again as the software locked up every time)
I must be a little harsh...why 232 port and not a 485? This puts the Do-More really behind. I don't want to stock one more interface module. Poll Question: Ask the users how many times they use the 232 port...probably 0. We can't even to a GS3 VFD without an adapter which takes up space.
Do-More to C-More Micro is extremely painful because the Timer Variables are in ms and not selectable like in a Click.
with that said, it is a great plc....Bonus BCD is dead!
-
I have several of them out at this point and besides the learning curve all are performing well. Points to consider:
extensive use of tasks in my programming structure causes Comm fault when I view "all status"
(won't ever click that one again as the software locked up every time)
I must be a little harsh...why 232 port and not a 485? This puts the Do-More really behind. I don't want to stock one more interface module. Poll Question: Ask the users how many times they use the 232 port...probably 0. We can't even to a GS3 VFD without an adapter which takes up space.
Do-More to C-More Micro is extremely painful because the Timer Variables are in ms and not selectable like in a Click.
with that said, it is a great plc....Bonus BCD is dead!
If you have a program causing status issues, we would really love to have a copy so we can fix it. That shouldn't be happening...at all. If you are willing, please PM me.
As for the 232 vs 485, at no time has ADC ever suggested that 485 should have been preferred over 232. If there is sufficient market demand for it, we are happy to build it.
-
As for the 232 vs 485, at no time has ADC ever suggested that 485 should have been preferred over 232. If there is sufficient market demand for it, we are happy to build it.
Historically, 232 would have been semi-preferred for a programming port over 485, but I think anymore most people will program via Ethernet or USB, and even for serial, nobody has 232 ports anymore anyways, so they're going to need a USB-232 converter, and those are just as readily available and just as cheap in USB-485.
Where the 485 would be missed is in multidrop Modbus mastering. I talk to drives a lot via 485 Modbus and will miss it if I don't have it. But yeah, we can easily convert to 485 outside the PLC, and there's so many other improvements vs. the Koyo product that this is hardly more than an annoyance.
-
Do-More to C-More Micro is extremely painful because the Timer Variables are in ms and not selectable like in a Click.
Is it my understanding that ADC just released Do-more support for C-more Micro. I think it should be much easier now.
-
Historically, 232 would have been semi-preferred for a programming port over 485, but I think anymore most people will program via Ethernet or USB, and even for serial, nobody has 232 ports anymore anyways, so they're going to need a USB-232 converter, and those are just as readily available and just as cheap in USB-485.
Where the 485 would be missed is in multidrop Modbus mastering. I talk to drives a lot via 485 Modbus and will miss it if I don't have it. But yeah, we can easily convert to 485 outside the PLC, and there's so many other improvements vs. the Koyo product that this is hardly more than an annoyance.
Sounds like you are building a case to do it. I'm certain that we don't have space to put the customary 5 pin terminal, so we'd have to stick with the RJ12. Not sure if there is a potential for it, but just imagining the screams of agony when that resulted in something getting broken...
-
I've used 250's as dumb Modbus I/O on 485 as well. Could be done with Ethernet on a Do-More I guess, though that doesn't work as well in a straight line topology, which is what I had when I used to do that. Very long machines with all power and I/O wiring contained within each section, and just an E-Stop and comms buss down the length.
[UPDATE: On further reflection, this scenario is irrelevant to the 232 vs 485 discussion. If I wanted to use 205 racks as remote I/O on 485, I'd just use a 250 like I used to. It's cheaper than a Do-More and since there's no or negligible ladder running, there's no advantage to using a DM anyway.]
-
Sounds like you are building a case to do it. I'm certain that we don't have space to put the customary 5 pin terminal, so we'd have to stick with the RJ12.
Yeah, I guess my one vote is for 485 over 232 if I have to pick one over the other, for the reasons stated. (need the 485 for multidrop Modbus, other std ports available for programming in the DM, nobody has 232 built-in anymore anyway...)
Not sure if there is a potential for it, but just imagining the screams of agony when that resulted in something getting broken...
No doubt. Are the signal levels sufficiently similar that nothing will get fried if you plug in a cable and it's 485 on one end and 232 on the other?
You might also consider some other modular connector (not RJ-45 obviously) to differentiate.
-
There are 3 basic uses for the CPU's serial port: 1) programming, 2) HMI slave comms, 3) external device master comms. Historically programming was the primary, although USB and Ethernet have greatly reduced that. So that leaves HMIs and devices. Guess what C-more Micro's port is...yes...RS232. Guess what disproportionately connects to that port...yes...C-more Micros. I'm sure there are some that would use the RS485 for the reasons that were stated, but the bulk of it is still RS232.
-
There are 3 basic uses for the CPU's serial port: 1) programming, 2) HMI slave comms, 3) external device master comms. Historically programming was the primary, although USB and Ethernet have greatly reduced that. So that leaves HMIs and devices. Guess what C-more Micro's port is...yes...RS232. Guess what disproportionately connects to that port...yes...C-more Micros. I'm sure there are some that would use the RS485 for the reasons that were stated, but the bulk of it is still RS232.
Ooh, good point. I never really warmed up to C-More's in general, but especially the Micros, so it takes me by surprise that they're the default MMI (just the Micros, not surprised about the C-Mores in general, but then those probably have a 485 port and sometimes Ethernet). And yeah, that sounds like probably the telling factor in that decision. Oh well, like I said, DM provides so many other advantages that this is a [very] minor issue and easy to work around anyway with an external converter.
-
I would much rather have RS232 on the CPU and use an isolated 485 converter, especially if you have any distance between drops. Plus my serial analyzer works better with RS232.
-
With regards to your original question of our experience with the Do-More, I absolutely love it. I don't have a lot of experience with PLC's, but I did some limited work with DL06 units a few years ago. A decision was recently made to try doing a lot of applications in house via PLC that were previously done manually or via embedded controls developed/provided by another group. When I started looking at PLC's to utilize, I was very happy to discover that the Do-More had come out. From my perspective, it's a massive improvement over the DL line. We are currently in the midst of developing our first application using the Do-More and I plan to utilize it almost exclusively. (Maybe a PAC3000 instead for a few aggressive applications further down the road.) I am especially happy about the move from BCD and the improvements to memory structure in general, along with the ability to organize the programming into code blocks.
I may be a little unusual in my uses, but one of the things that I would really like to see as a future capability is a very easy way to log data, errors, messages, etc... in a way that is easy for a technician/operator to read off onto a laptop as needed. We are going to be using most of our PLC applications in remote locations and situations where there is no network capability. As a result, I'd love to see something like the micro SD setup you often have with smart phones. I would love to be able to install a micro SD card in a Do-More and then have the card mount in Windows Explorer when I connect a laptop to the USB programming port. Ideally, there would be commands in the PLC to easily create files on the storage card and then write log data to those files which could then be easily accessed when a computer was connected to the USB port. This type of storage configuration would also let me take the "Downloadable Documentation" concept even further by allowing me to store all of the documentation for the entire machine on the PLC in any software format I desired. I could include troubleshooting procedures, operator aids, wiring schematics, etc..., and not just the PLC programming documentation.
One last feature that would be helpful for some of our applications would be the ability to have the Do-More go into a low power standby mode and then only power up to run mode when a time/date is reached or an outside event sends a wake up signal. (We have applications where we would like to have a controller connected to a 12V battery in a field location power up and run after potentially long wait periods.) We can continue to utilize embedded controllers, but it would be nice to use PLC's in some of these applications. I guess I could play around with separate devices which make or break the power supply to the PLC, but it would be more elegant if the PLC had a built in sleep mode. (I realize that this is probably not a common user request, so I understand if it doesn't make business sense to add a feature like this.)
Thanks. Keep up the good work.
-
With regards to your original question of our experience with the Do-More, I absolutely love it. I don't have a lot of experience with PLC's, but I did some limited work with DL06 units a few years ago. A decision was recently made to try doing a lot of applications in house via PLC that were previously done manually or via embedded controls developed/provided by another group. When I started looking at PLC's to utilize, I was very happy to discover that the Do-More had come out. From my perspective, it's a massive improvement over the DL line. We are currently in the midst of developing our first application using the Do-More and I plan to utilize it almost exclusively. (Maybe a PAC3000 instead for a few aggressive applications further down the road.) I am especially happy about the move from BCD and the improvements to memory structure in general, along with the ability to organize the programming into code blocks.
Thanks for the kind words. I would be interested in hearing the specifics of how you would choose between the PAC and Do-more. One of the big questions that has come up is why you would choose one over the other. Being the proud papa I am, it's pretty obvious that I would choose Do-more in every case that it would do the job, but I would love to be able to see that same decision from an unbiased user's perspective. I'm sure there are some things the PAC does better than we do, and I know their I/O counts go much higher than ours...although I/O shouldn't be an issue much longer. The Ethernet Expansion I/O feature is shaping up very nicely and will be out as quickly as we can get it tested and solid.
I may be a little unusual in my uses, but one of the things that I would really like to see as a future capability is a very easy way to log data, errors, messages, etc... in a way that is easy for a technician/operator to read off onto a laptop as needed. We are going to be using most of our PLC applications in remote locations and situations where there is no network capability. As a result, I'd love to see something like the micro SD setup you often have with smart phones. I would love to be able to install a micro SD card in a Do-More and then have the card mount in Windows Explorer when I connect a laptop to the USB programming port. Ideally, there would be commands in the PLC to easily create files on the storage card and then write log data to those files which could then be easily accessed when a computer was connected to the USB port. This type of storage configuration would also let me take the "Downloadable Documentation" concept even further by allowing me to store all of the documentation for the entire machine on the PLC in any software format I desired. I could include troubleshooting procedures, operator aids, wiring schematics, etc..., and not just the PLC programming documentation.
We actually developed a small file system (a few megabytes) for Do-more. It didn't make the initial release due to schedule, but it is definitely something that we will be adding in the future. I think it would be everything you want, minus the removable media.
I don't know if you know this, but you can already attach a document to the downloaded project. It's limited to 1MB, but it is in there now under 'Tools>Attach User Document...'.
One last feature that would be helpful for some of our applications would be the ability to have the Do-More go into a low power standby mode and then only power up to run mode when a time/date is reached or an outside event sends a wake up signal. (We have applications where we would like to have a controller connected to a 12V battery in a field location power up and run after potentially long wait periods.) We can continue to utilize embedded controllers, but it would be nice to use PLC's in some of these applications. I guess I could play around with separate devices which make or break the power supply to the PLC, but it would be more elegant if the PLC had a built in sleep mode. (I realize that this is probably not a common user request, so I understand if it doesn't make business sense to add a feature like this.)
Sounds like an interesting feature, but as you suspect, not a common one. In truth I'm not even sure how it would be approached...but it sounds *very* cool.
Thanks for the feedback!
-
Maybe a PAC3000 instead for a few aggressive applications further down the road.
I know very little about the P3K's, but my image of them certainly is not as the bigger, more capable alternative to the Do-More. Quite the opposite, in fact.
We are going to be using most of our PLC applications in remote locations and situations where there is no network capability.
You might consider radio modems. I'm doing a project right now with ultimately multiple PLC's anywhere from a few hundred yards to about 5 miles from the HMI PC, and the radios claim they'll do up to 40 miles optimally. Digi, 1 watt, $300 a pop. The remote stations are totally solar powered with deep cycle batteries for storage.
-
I would be interested in hearing the specifics of how you would choose between the PAC and Do-more.
The only job that I was thinking about looking at the PAC for is a combination data acquisition & control application in a testing lab we have. A vendor that did some PLC work for us a couple of years ago recommended that we look at using the PAC due to high speed and large # of inputs. To be honest, I haven't looked at it in much detail because it will be a couple of years before we get the funding for that job. I had planned to look into the PAC at that time and compare it vs a dedicated commercial data acquisition system combined with DL205 PLC's for the control part. Maybe the Do-more would be the best choice? I'll certainty look at it when we get closer to doing the job.
We actually developed a small file system (a few megabytes) for Do-more. It didn't make the initial release due to schedule, but it is definitely something that we will be adding in the future. I think it would be everything you want, minus the removable media.
I don't really care if the media is removable. I just figured that would give the end user a way to install as much as they want for their particular application while saving the manufacturer the cost of building in the memory in every CPU whether it is needed or not. My real desire is the ability to easily log / write to the storage area and then have it be accessed via USB without special software when I get the chance to connect a laptop to the PLC. Maybe the file system feature you mentioned will be the ticket.
I don't know if you know this, but you can already attach a document to the downloaded project. It's limited to 1MB, but it is in there now under 'Tools>Attach User Document...'.
I saw that via your start page topics, but if I remember right, it was limited in the types of files that could be downloaded, plus the size limitation. Is that right?
You might consider radio modems. I'm doing a project right now with ultimately multiple PLC's anywhere from a few hundred yards to about 5 miles from the HMI PC, and the radios claim they'll do up to 40 miles optimally. Digi, 1 watt, $300 a pop. The remote stations are totally solar powered with deep cycle batteries for storage.
For a number of different reasons, the radio option often isn't allowed or worthwhile for many of our applications. With regards to your application, be ready to invest some real time and effort into getting the radios to work. We've done some work connecting field equipment via radios supplied by another group in our company. The radio jobs seem to be very temperamental and work some times in some places, but not in others. Our experience is also that you will not get anywhere near the range they claim and the cheap systems end up costing more in the long run that just paying the money for the more expensive systems up front. If you're talking short ranges, and flat open locations, you have a lot fewer problems. Long range mesh systems in hilly locations with trees are the worst situations. I've got a researcher that I support who is looking at installing a bunch of computer controlled instruments out in the desert this fall and interfacing with them via a wireless Ethernet system. We haven't started any field testing yet, but we were looking at a system made by Afar http://www.afar.net/wireless/ethernet-bridge/ (http://www.afar.net/wireless/ethernet-bridge/) that looks pretty good on paper. Their support engineers have been helpful too.
-
With regards to your application, be ready to invest some real time and effort into getting the radios to work. We've done some work connecting field equipment via radios supplied by another group in our company. The radio jobs seem to be very temperamental and work some times in some places, but not in others. Our experience is also that you will not get anywhere near the range they claim and the cheap systems end up costing more in the long run that just paying the money for the more expensive systems up front. If you're talking short ranges, and flat open locations, you have a lot fewer problems. Long range mesh systems in hilly locations with trees are the worst situations.
Optimistic range ratings have been my [somwhat limited] experience too, so when possible we get substantially more rated range than what's actually needed, and test. In this case, we tested at about 150% of the range over similar terrain (slightly rolling desert with brush) with good results at about 5' less mast height than we'll have in reality. Additionally I'm designing the app to cache all necessary control data at the remote, so it can tolerate intermittent comms.
I've got a researcher that I support who is looking at installing a bunch of computer controlled instruments out in the desert this fall and interfacing with them via a wireless Ethernet system. We haven't started any field testing yet, but we were looking at a system made by Afar http://www.afar.net/wireless/ethernet-bridge/ (http://www.afar.net/wireless/ethernet-bridge/) that looks pretty good on paper. Their support engineers have been helpful too.
Thank you for the recommendation! We'll keep them in mind.
-
I don't really care if the media is removable. I just figured that would give the end user a way to install as much as they want for their particular application while saving the manufacturer the cost of building in the memory in every CPU whether it is needed or not. My real desire is the ability to easily log / write to the storage area and then have it be accessed via USB without special software when I get the chance to connect a laptop to the PLC. Maybe the file system feature you mentioned will be the ticket.
The issue of file systems, and particularly in relation to removable media, is that you really need an OS to effectively manage them. In an effort to build the fastest PLC at the lowest cost, we chose not to use an OS for the DM1. We definitely have plans for other CPUs in the future, and an OS will likely play a role. You can see where that leads. ;)
I saw that via your start page topics, but if I remember right, it was limited in the types of files that could be downloaded, plus the size limitation. Is that right?
It's limited to a single file of up to 1MB that can be displayed by your web browser.
-
BobO,
Do you believe that the Do-More would be capable of data acquisition? Say system would have at most eight analog inputs and trying to write data at a max of 100Hz, most typical scenerios would be 10Hz. I was thinking a direct connections with InduSoft Web Studio SCADA and collection to central SQL type database.
Thanks!
-
The Do-More would also be required to control the pressure system (PID proportional valves, on/off valves, etc). Data acquisition would be sending analog signals from pressure transducers, flow meters for trending and chart recording.
-
BobO,
Do you believe that the Do-More would be capable of data acquisition? Say system would have at most eight analog inputs and trying to write data at a max of 100Hz, most typical scenerios would be 10Hz. I was thinking a direct connections with InduSoft Web Studio SCADA and collection to central SQL type database.
Thanks!
The data acquisition part is no problem. I would need a better understanding of how you will be communicating with the server before I would commit to 100hz. I'm certain it is possible, but your comm will dictate whether it is practical.
-
The Do-More would also be required to control the pressure system (PID proportional valves, on/off valves, etc). Data acquisition would be sending analog signals from pressure transducers, flow meters for trending and chart recording.
...and this part would be no sweat too.
-
BobO,
Do you believe that the Do-More would be capable of data acquisition? Say system would have at most eight analog inputs and trying to write data at a max of 100Hz, most typical scenerios would be 10Hz. I was thinking a direct connections with InduSoft Web Studio SCADA and collection to central SQL type database.
Thanks!
Pretty sure that the physical limitations of the analog modules would prevent 100Hz. You could do it, but you wouldn't get new data for every log.
-
Pretty sure that the physical limitations of the analog modules would prevent 100Hz. You could do it, but you wouldn't get new data for every log.
Yeah, I'd say you are right. There is nothing that would prevent it from Do-more's perspective (CPU speed, backplane throughput, etc), but the analog may not source it that fast.
<...time passes...>
I just did a very quick test, using a delta contact with an analog input feeding a FREQCNT instruction to compute the rate that data changes. The analog input is fed by a resistor voltage divider and other than noise is not changing, so I am probably not getting the full number of conversions. With that test, I am seeing around 45-50Hz. It also bears mention that the analog card is in an EBC rack that I am talking to with the new Ethernet Expansion I/O feature of the DM1E, which is updating at about 5ms....with analog and 4 CTRIO modules in the base. I'm quite pleased with the performance. ;)
<...more time passes...>
OK...admittedly I'm just showing off now...but with a delta contact, FREQTMR instruction, a math box to round the frequency, and an increment instruction, I created a histogram to determine where the bulk of the updates were occurring. The result is clusters at 33Hz, 45Hz, and 66Hz, with the bulk of those at 45Hz. Yes, actually, I do think MacGuyver would be proud. ;)
-
Yes, actually, I do think MacGuyver would be proud. ;)
Only if you used a toothbrush and some thermite made solely from stuff you found under the bathroom sink! ;D
-
I just finished my first real job with the Do-more and I'm thrilled with it. One area where I did encounter problems is working with the C-more. One thing that someone else commented on is the fact that the c-more can't see user defined memory blocks. One other problem that I haven't seen anyone comment on is the fact that the c-more gets really flaky when displaying UDT structure members. They display correctly in some locations, but a direct copy of the display object will show incorrect values in a different screen. I reported this to Automation Direct and they ended up suggesting that I write the UDT structure members to V locations and then point the c-more to those memory locations instead.
Just out of curiosity, any chance that Host will decide to design the next generation c-more? I'd love to see you bring the same inovation and fresh attitude to the design of a HMI that interfaces natively with Automation Direct PLC's, that you brought to the design of the Do-more.
-
I just finished my first real job with the Do-more and I'm thrilled with it. One area where I did encounter problems is working with the C-more. One thing that someone else commented on is the fact that the c-more can't see user defined memory blocks. One other problem that I haven't seen anyone comment on is the fact that the c-more gets really flaky when displaying UDT structure members. They display correctly in some locations, but a direct copy of the display object will show incorrect values in a different screen. I reported this to Automation Direct and they ended up suggesting that I write the UDT structure members to V locations and then point the c-more to those memory locations instead.
Just out of curiosity, any chance that Host will decide to design the next generation c-more? I'd love to see you bring the same inovation and fresh attitude to the design of a HMI that interfaces natively with Automation Direct PLC's, that you brought to the design of the Do-more.
Glad to hear that Do-more did more! We're busy adding features for 1.1, after which it will Do-even-more!
As for C-more, ideally ADC will continue to work with Koyo to bring the Do-more driver up to standard. At some point in the not too distant future we will be developing a specification to allow other panel manufacturers to access Do-more natively. A little competition has a way of bring out the innovative spirit, so we'll see what happens.
-
Glad to hear that Do-more did more! We're busy adding features for 1.1, after which it will Do-even-more!
Great! When's it coming out? Will the "Small File System" you mentioned in your message on February 28, 2013, @ 11:09:58 am be part of 1.1?
On a related note, two things that would be nice features to get at some point in the future are:
- The ability to copy and paste part of a rung into another rung. Several times when debugging a program I've ended up developing some complicated logic arrangement to handle some unusual situation that comes up during development testing and I end up wanting to add that logic into existing rungs in multiple stages or code locations.
- A JMPNow command that jumps immediately without processing the rest of the rungs in the stage.
Of the two, my highest priority would be the JMPNow command. I don't want to replace the current jump command, I'd just like this as an additional option. Obviously there are a couple of ways to avoid running the remaining rungs without a command like this, but it would make coding faster and more elegant if it were available.
-
The big 1.1 feature is built-in Ethernet expansion I/O, with initial support for H2-EBC100, T1H-EBC100, and GS-EDRV100. No file system yet, but that shouldn't be too much longer.
The jump now instruction wouldn't be too difficult and I can see how it would be useful, although my gut reaction is that you may be doing too much in the stage. A handy workaround is to use the stage bit as a condition, since the JMP immediately clears the it even though it doesn't immediately jump out of the code.
The editor is a bit harder, but we are definitely wanting to do some work there too. Key thing is to deal with getting the features in Do-more that are limiting us (like no expansion I/O). Once we get those out of the way, we can start looking at some of the other 'nice to haves'.
-
my gut reaction is that you may be doing too much in the stage.
I had the same thought. You've got a ton of stages to work with, use them. I try to limit looking for 1 condition in each stage. If your process dictates that you are monitoring for multiple simultaneous events, then have parallel threads in either stages, tasks or programs.
-
JMPNOW could not necessarily really Jump to THAT stage, but to the NEXT stage in ladder memory. We could make it Jump (literally) to THAT stage also, but it would break the general flow of the ladder logic. Other entire stages logic would be SKIPPED when jumping "forward" - THIS IS BAD. Or, if moving backwards in program memory, would generate a LOOP, which is ALSO bad. Literally jumping backwards would include executing OTHER stages TWICE in the SAME SCAN (Timers would not time correctly, et. al.).
I am going to guess that you really want it to jump to THAT stage, but that would require YOU to ENSURE that THAT stage is the "next" one in memory, which is a non-obvious burden/responsibility on the user. We could require Do-more to make sure the JMPNOW stage is the NEXT one. I would guess that would be the only way to make it work as expected. That would also imply that you could only JMPNOW to Stage 10 from JUST ONE STAGE, the one preceding it, implying that S5 and S6 could NOT BOTH JMPNOW to Stage 10.
This construct I think implies you are probably doing too much within your stages (see other comments), cuz the side effects of a literal JMPNOW will be worse than any logic you think you need to skip in your current implementation.
-
JMPNOW could not necessarily really Jump to THAT stage, but to the NEXT stage in ladder memory. We could make it Jump (literally) to THAT stage also, but it would break the general flow of the ladder logic. Other entire stages logic would be SKIPPED when jumping "forward" - THIS IS BAD. Or, if moving backwards in program memory, would generate a LOOP, which is ALSO bad. Literally jumping backwards would include executing OTHER stages TWICE in the SAME SCAN (Timers would not time correctly, et. al.).
I am going to guess that you really want it to jump to THAT stage, but that would require YOU to ENSURE that THAT stage is the "next" one in memory, which is a non-obvious burden/responsibility on the user. We could require Do-more to make sure the JMPNOW stage is the NEXT one. I would guess that would be the only way to make it work as expected. That would also imply that you could only JMPNOW to Stage 10 from JUST ONE STAGE, the one preceding it, implying that S5 and S6 could NOT BOTH JMPNOW to Stage 10.
This construct I think implies you are probably doing too much within your stages (see other comments), cuz the side effects of a literal JMPNOW will be worse than any logic you think you need to skip in your current implementation.
I guess I didn't explain my idea very clearly. It wasn't that I wanted to jump instantly to other parts of the ladder logic. What I was thinking is that there would be times where it would be nice to automatically disable the rest of the logic in the stage I'm running once I get to a decision point that results int a jmp command. Most of the time, I run through a stage and jump at the end. Occasionally; however, I'll get a stage which contains several interconnected decisions. The last time this happened, I was in a stage where I was preparing to run a process and depending on a number of different factors, I needed to either jmp into the first stage of running the process, jmp to an alternative version of the process, exit that mode entirely, or skip that process stage entirely and start the next process down the line. My previous programming experience before PLC's was FORTRAN 77 (years ago) and I guess I tend to think in IF,THEN,ELSE Blocks.
As I said before, disabling the remaining few rungs in a stage usually isn't needed. In those cases in the future where I do want to skip the remaining rungs, I'll follow BobO's advice and use the stage bit as a condition. (I wasn't thinking about the fact that the stage bit turns off at the instant the jmp command is encountered.)
-
We can definitely help you there.
When you JMP, the stage you are in has ITS bit turned OFF. Hence, you can easily utlize this fact when branching (like a C switch statement or IF ELSE IF ELSE IF ELSE IF... type construct.
If you are in Stage 10, use S10 contact as a permissive of the other JMP branch conditions
[SG S10]
...
S10 X0 S20
-] [---] [------( JMP )
S10 X5 S21
-] [---] [------( JMP )
S10 X7 S22
-] [---] [------( JMP )
S10 X2 S23
-] [---] [------( JMP )
You might also look at the JMPI (Indexed Jump) if you have a "state" value that you can easily index 0..n-1 to jump to n different stages starting at Sj to Sj+n-1, i.e. index value V20 equal to 0..9 with JMPI S100 would jump to Stage S100 thru 109 based off the value of V20 (note that the last stage in the series is actually a final "else" or "exception" stage when V20 is out of range, so any value other than 0..8 would JMP to Stage S109.)
-
If you are in Stage 10, use S10 contact as a permissive of the other JMP branch conditions
[SG S10]
...
S10 X0 S20
-] [---] [------( JMP )
S10 X5 S21
-] [---] [------( JMP )
S10 X7 S22
-] [---] [------( JMP )
S10 X2 S23
-] [---] [------( JMP )
Your code example is exactly what I'll probably do in the future. I knew that the stage bit turned off when you jumped from the stage and I use that fact in other locations when I need to make decisions based on what stage is or is not running. Before BobO mentioned it; however, I wasn't making the mental connection that the stage bit turned off at the instant that the jmp command was encountered. I was just assuming the the bit turned off when you actually finished the stage. In hind sight, the way it actually works makes sense, but I just didn't make the connection.
On a side note, these tips and suggestions that I've been picking up on this forum have been very helpful. I don't have ready access to anyone else at work who uses PLC's with ladder logic programming, and so this forum has been a real blessing as a source of information.
-
I don't have ready access to anyone else at work who uses PLC's with ladder logic programming, and so this forum has been a real blessing as a source of information.
Here are some others:
- Designer's Start Page: click on any of the 8 topics to browse various topics.
- Designer's Tip of the Day: short tid bits
- Designer's Help System: there is good information throughout the topics that provide interesting details about various views, tools, utilities in Do-more
- http://www.do-morePLC.com : Lots of articles and free videos to help you learn about Do-more
- http://www.interconnectingautomation.com : I think ADC is still providing FREE 30 day's worth of Do-more training for every CPU. There's advanced training there also.
And of course, this forum, which is actually all of various customers and users out there that provide helpful answers, tips, ideas, issues, etc.
-
On a side note, these tips and suggestions that I've been picking up on this forum have been very helpful. I don't have ready access to anyone else at work who uses PLC's with ladder logic programming, and so this forum has been a real blessing as a source of information.
Glad to hear it! We're happy to help, so please feel free to ask anything. We're obviously biased, but we feel that Do-more is far more powerful that most are aware of. As we answer these questions we put 'best practices' out for others to read, and we aid the questioner in learning to use Do-more more fully. In time there will be a bunch of folks out there that know what Do-more can really do!
-
Just getting started with my first do-more project. First disappointment, nicknames. BobO says we should be using nickmanes instead of actual memory locations. I think it is a great idea, so why did you narrow the available nicknames? We are still limited to 16 characters and special characters such as "?!" are no longer allowed.
With DS5 I would use "CONVEYOR1_ON" as an output, "CONVEYOR1_ON?" as an input, "CONVEYOR1!" as a fault.
How do others handle nicknames?
-
Just getting started with my first do-more project. First disappointment, nicknames. BobO says we should be using nickmanes instead of actual memory locations. I think it is a great idea, so why did you narrow the available nicknames? We are still limited to 16 characters and special characters such as "?!" are no longer allowed.
With DS5 I would use "CONVEYOR1_ON" as an output, "CONVEYOR1_ON?" as an input, "CONVEYOR1!" as a fault.
How do others handle nicknames?
First, I greatly regret our decision to stick with 16 characters. The decision was made early in the development long before we had a clue of where this was going. In retrospect, it was a very bad decision. It's something that can be changed though, and we might address it in the future.
The loss of special characters is easy to justify though. Math in Do-more uses real expressions like any high level language. It was necessary to restrict nicknames to something similar to a C language symbol to make those expressions possible. There are no limitations on the extra info or description fields though.
-
mhw, I never bothered with nicknames (unique ID's that can actually be used in lieu of an address) specifically because they're too short and too constrained to store a description that I'd like.
So I've always just used native addresses, but with good descriptions (multi-line free form text that doesn't have to be unique and which can't be used as an address).
With Do-More, I expect to do the same thing, except that a lot of things in programming lend themselves to the use of structures, or user-defined data types. I'll probably use heap items where that makes sense, which is kind of analogous to using nicknames vs. native addressing, in the sense that they're named more functionally rather than with reference to their storage location.
BobO, can we do free-form UDT's in heap yet, or just one-type arrays for now?
-
mhw, I never bothered with nicknames (unique ID's that can actually be used in lieu of an address) specifically because they're too short and too constrained to store a description that I'd like.
Old school, like Bernie. ;) No criticism here...I want you to do what works best for you...but I have a hard time wrapping my head around the thought that you would find WX32 or X129 easier than names like CoolingBathTemp or FwdCarriageLmt, or that you would consider those names to be of limited value. I've been coding for 30+ years, and 80% of the variables I use in code are 16 characters or less, and 95% or more are 20 or less. Even though C++ doesn't impose any meaningful limit, code readability dictates that concise names are better.
BobO, can we do free-form UDT's in heap yet, or just one-type arrays for now?
User defined types are on the road map, but are not there yet. DmD would fully support then now, but the UI and project management/portability issues have to be resolved. Dynamic is cool. It is also a major pain in the rump to make work properly.
-
Old school, like Bernie. ;) No criticism here...I want you to do what works best for you...but I have a hard time wrapping my head around the thought that you would find WX32 or X129 easier than names like CoolingBathTemp or FwdCarriageLmt, or that you would consider those names to be of limited value. I've been coding for 30+ years, and 80% of the variables I use in code are 16 characters or less, and 95% or more are 20 or less. Even though C++ doesn't impose any meaningful limit, code readability dictates that concise names are better.
[shrug] I don't know -- I find the misspelled/abbreviated names with no spaces unpleasant to look at, and the numbers aren't that hard to remember (especially with a printout of my Excel memory map design right there on the desk). In sort of a similar vein, I barely do comments. I do the descriptions well enough that you can look at the rung and tell what it does, and I get all that for free just from having written the descriptions once (or it would work with nicknames too), so why bother with comments, except in unusual cases (or to mark off code blocks)?
User defined types are on the road map, but are not there yet. DmD would fully support then now, but the UI and project management/portability issues have to be resolved. Dynamic is cool. It is also a major pain in the rump to make work properly.
Looking forward to getting them, but understand that you guys need to take the time to do it right.
-
I would say that the benefit of well described points vs not needing comments speaks heavily of the type of applications you do and/or the way you code them. Certain problems are inherently state based, others are sequence, and still others are algorithmic...and perhaps more to the point...different folks approach problems in different ways, and the same person will approach the same problem in different ways with different tools. I'm sure that I would write different code than you, and the Do-more code I write bears little resemblance to DL code I write.
Meaning, there is a whole lot of adapting going on...and there is nothing right or wrong about it. Use what works for you.
-
I used to write comments "for the other guy, who might have to figure out what I'm doing". Over the past few years, I do it for the same reason, it's just "the other guy" is ME!
Who here remembers their last Senior Moment? Anyone? Anyone? If you do, then it wasn't a Senior Moment. ;D
-
I would say that the benefit of well described points vs not needing comments speaks heavily of the type of applications you do and/or the way you code them. Certain problems are inherently state based, others are sequence, and still others are algorithmic...and perhaps more to the point...different folks approach problems in different ways, and the same person will approach the same problem in different ways with different tools. I'm sure that I would write different code than you, and the Do-more code I write bears little resemblance to DL code I write.
Excellent point. I'm sure that's exactly the case.
-
Who here remembers their last Senior Moment? Anyone? Anyone? If you do, then it wasn't a Senior Moment. ;D
LOL -- if you get them often enough, they sort of merge into a "stream of unconsciousness"!
-
Hi Bob,
I spoke with Greg late last year trying to decide to make the move the Do-More. I have a 8 unit system that must work with an existing Lookout system. Greg talked me through getting it to work but now I cannot repeat getting the "C" objects to write to the "DLC" objects in Do-More. I am using the MOVER to get V data out but I am stumbed on the C bit control. If I cannot make this work ASAP, I will have to revert back to the DL205 series!
HELP?
-
Hi Bob,
I spoke with Greg late last year trying to decide to make the move the Do-More. I have a 8 unit system that must work with an existing Lookout system. Greg talked me through getting it to work but now I cannot repeat getting the "C" objects to write to the "DLC" objects in Do-More. I am using the MOVER to get V data out but I am stumbed on the C bit control. If I cannot make this work ASAP, I will have to revert back to the DL205 series!
HELP?
I'm actually on vacation right now and I think Greg is too, but hopefully Mike or Franj or somebody else there can talk you through it. I would even be happy to help, but I have no phone and limited internet. If you will PM a phone number to one of us, we'll call and talk you through it.
-
I just completed my first large Do-more project 2 PLC's, 300+ inputs, 4 citrio counters, 10 analog channels. I wrote the HMI's in VB.net, comms were Modbus TCP.
Requests:
Expand the Do-More to include all 205 hardware available, or at least more common ones.....even just for the convinence of not having to research which specific devices are compatable and are not.
For some expansion, I prefer using the D2-CM/EM over the ERM/EBC100. I am new to using the ERM and dont use all of its functionality, but my take is:
Addressing expansion modules with the ERM should be more automatic and built into the Do-More Software along side the base I/O addressing. As well, addressing ERM Expansion should use decimal addressing. The ERM/EBC definately have their place, but if I need an expansion rack right next to my base, the D2-CM/EM seems cleaner, faster, easier, and cheaper.....like it is in the 205.
I have been in many endless arguments about data tag labeling and mapping...but at the end of the day, it is inefficient organizing data by type. I would prefer to be able to label a tag whatever I want, select what data type it is (to include I/O, but I understand structures there), select retention, etc, and then organize my tags alphabetically. If I wanted them organized by type, then I would prefix the name of the tag as such. If I need to know from the name if a bit is an in, out, or bit...then I just put a X,Y,C in the name as I see fit, otherwise I will look at the data table for more info about its structure. Nicknames almost serve this purpose...if I could organize the xref by nicknames I would be happy, but also, need to expand the # of chars, and types of chars for nicknames.
If we are going to continue organizing by type.....do it alphabetically, or at least have the option. The list organization of the Xref chart slows me down from finding my tag. I roughly know how it is organized when I am looking for common tags: X,Y,D,R,T,C....but if the whole thing was alphabetical, my time to find a tag xref would be significantly decreased.
Sometimes its the little things...I do find that mouse scrolling up and down in the ladder logic is jumpy...and sometimes unpredictable? I find myself getting lost, overshooting, undershooting, mostly when I have to be on a laptop and have a smaller screen....but it seems like the up and down could be rethought or smoothed out somehow? I think because it jumps in increments of rungs, which aren't always the same height, my eyes have a hard time following a rung in its movement. Maybe the scroll needs to be consistant smaller lengths to smooth it out.
Just throwing my 2 cents in, which might be a repeat of what others have said..but this is me voting on what I would improve initially.
The Do-More software and Hardware is a major improvement. As well, it is a step in the right direction, keep going with it. I am an extremely satisfied customer, and will always use a Do-More PLC for every application I can apply it to.
-
Requests:
Expand the Do-More to include all 205 hardware available, or at least more common ones.....even just for the convinence of not having to research which specific devices are compatable and are not.
What is not supported that you wish to use (other than EM/CM)?
For some expansion, I prefer using the D2-CM/EM over the ERM/EBC100. I am new to using the ERM and dont use all of its functionality, but my take is:
Addressing expansion modules with the ERM should be more automatic and built into the Do-More Software along side the base I/O addressing. As well, addressing ERM Expansion should use decimal addressing. The ERM/EBC definately have their place, but if I need an expansion rack right next to my base, the D2-CM/EM seems cleaner, faster, easier, and cheaper.....like it is in the 205.
Ironically, the reason we chose not to support the EM/CM was precisely related to your first point. There are too many limitations with EM/CM in performance and supported modules. After discussions with the product manager at ADC, the decision was made to not support. Knowing that people would need to expand systems, however, we have always planned to support I/O expansion through the built-in Ethernet port. Which...
...as of version 1.1, to be released in the next couple of weeks, you will have fully native support for up to 16 slave devices. Slaves can be H2-EBC100, T1H-EBC100, and GS-EDRV100. The entire thing is very clean, high performance, and all associated I/O looks exactly like modules in the local rack...including CTRIO/2 support in both 205 and Terminator racks.
I have been in many endless arguments about data tag labeling and mapping...but at the end of the day, it is inefficient organizing data by type. I would prefer to be able to label a tag whatever I want, select what data type it is (to include I/O, but I understand structures there), select retention, etc, and then organize my tags alphabetically. If I wanted them organized by type, then I would prefix the name of the tag as such. If I need to know from the name if a bit is an in, out, or bit...then I just put a X,Y,C in the name as I see fit, otherwise I will look at the data table for more info about its structure. Nicknames almost serve this purpose...if I could organize the xref by nicknames I would be happy, but also, need to expand the # of chars, and types of chars for nicknames.
I won't argue or debate this, except to say that Do-more is, cool new features notwithstanding, a conventional PLC with a conventional PLC view of memory. Our efforts to expand the more tag-centric features tend to get us verbal abuse from those who don't like them. That said, we do have plans to create one or more new views that should be more appropriate for tag-centric people, and we will certainly consider your feedback when we spec them.
Sometimes its the little things...I do find that mouse scrolling up and down in the ladder logic is jumpy...and sometimes unpredictable? I find myself getting lost, overshooting, undershooting, mostly when I have to be on a laptop and have a smaller screen....but it seems like the up and down could be rethought or smoothed out somehow? I think because it jumps in increments of rungs, which aren't always the same height, my eyes have a hard time following a rung in its movement. Maybe the scroll needs to be consistant smaller lengths to smooth it out.
Mouse scrolling is definitely an emulation of sorts and I'm certain it can be improved. I tend to avoid the mouse for everything except menus and view selection, so I deal with by not using it. ;)
-
What is not supported that you wish to use (other than EM/CM)?
I didn't look back at the specifics....but I remember purchasing a couple analog cards that weren't supported? There were similiar alternatives that worked. I just think all the analog, and discrete I/O cards should be supported if they are not already.
Ironically, the reason we chose not to support the EM/CM was precisely related to your first point. There are too many limitations with EM/CM in performance and supported modules. After discussions with the product manager at ADC, the decision was made to not support. Knowing that people would need to expand systems, however, we have always planned to support I/O expansion through the built-in Ethernet port. Which...
...as of version 1.1, to be released in the next couple of weeks, you will have fully native support for up to 16 slave devices. Slaves can be H2-EBC100, T1H-EBC100, and GS-EDRV100. The entire thing is very clean, high performance, and all associated I/O looks exactly like modules in the local rack...including CTRIO/2 support in both 205 and Terminator racks.
I didn't realize the advantages of the EBC until now...which at the time that I did my last project, I dont think these advantages were fullfilled. At that time I was using the EBC, I still had to keep my counters, serial comms, and analogs in the base, and then I was just annoyed with the I/O addressing for the remote racks. Looks like going down the road with the EBC is way better, considering that you are streamlining the addressing, and expanding the types of cards for remote racks. I very often run out of base I/O slots; to be able to put counters, analogs, and maybe some comm cards wherever I want would be extremely benificial to me.
I won't argue or debate this, except to say that Do-more is, cool new features notwithstanding, a conventional PLC with a conventional PLC view of memory. Our efforts to expand the more tag-centric features tend to get us verbal abuse from those who don't like them. That said, we do have plans to create one or more new views that should be more appropriate for tag-centric people, and we will certainly consider your feedback when we spec them.
I like using the nicknames with the Do-More software, it works well for me writting code and finding what variable I am trying to reference as I write the code. I just wish that the X-ref would allow for organization by the nickname alphabetically. Right now, the quickest way for me to find the X-refs for a specific variable, is place a temp operator in the code, type in the nickname so I can highlight it and get the x-ref to load it. Then I delete the temp operator. Alternatively, I also reference external Excel/Access tracking documents. Neither would be required if I could organize my x-refs by nickname.
-
What is not supported that you wish to use (other than EM/CM)?
I didn't look back at the specifics....but I remember purchasing a couple analog cards that weren't supported? There were similiar alternatives that worked. I just think all the analog, and discrete I/O cards should be supported if they are not already.
Well...I agree. And as far as I am aware, we support all discrete and analog I/O, and have from launch. Do you know where you heard otherwise?
Ironically, the reason we chose not to support the EM/CM was precisely related to your first point. There are too many limitations with EM/CM in performance and supported modules. After discussions with the product manager at ADC, the decision was made to not support. Knowing that people would need to expand systems, however, we have always planned to support I/O expansion through the built-in Ethernet port. Which...
...as of version 1.1, to be released in the next couple of weeks, you will have fully native support for up to 16 slave devices. Slaves can be H2-EBC100, T1H-EBC100, and GS-EDRV100. The entire thing is very clean, high performance, and all associated I/O looks exactly like modules in the local rack...including CTRIO/2 support in both 205 and Terminator racks.
I didn't realize the advantages of the EBC until now...which at the time that I did my last project, I dont think these advantages were fullfilled. At that time I was using the EBC, I still had to keep my counters, serial comms, and analogs in the base, and then I was just annoyed with the I/O addressing for the remote racks. Looks like going down the road with the EBC is way better, considering that you are streamlining the addressing, and expanding the types of cards for remote racks. I very often run out of base I/O slots; to be able to put counters, analogs, and maybe some comm cards wherever I want would be extremely benificial to me.
For 1.1, all discrete, analog, and CTRIOs are fully supported in Ethernet bases and appear as normal local I/O in the map. We do not support ECOM100, ERM100, or SERIO in expansion bases, due in part to the fact that taking as many as 8 hoses and aggregating them into 1 hose of the same bandwidth is functionally impossible...but that really doesn't begin to describe the real level of complexity. Trust me when I say it gets real ugly real fast. But hopefully full native I/O support will satisfy the need.
I won't argue or debate this, except to say that Do-more is, cool new features notwithstanding, a conventional PLC with a conventional PLC view of memory. Our efforts to expand the more tag-centric features tend to get us verbal abuse from those who don't like them. That said, we do have plans to create one or more new views that should be more appropriate for tag-centric people, and we will certainly consider your feedback when we spec them.
I like using the nicknames with the Do-More software, it works well for me writting code and finding what variable I am trying to reference as I write the code. I just wish that the X-ref would allow for organization by the nickname alphabetically. Right now, the quickest way for me to find the X-refs for a specific variable, is place a temp operator in the code, type in the nickname so I can highlight it and get the x-ref to load it. Then I delete the temp operator. Alternatively, I also reference external Excel/Access tracking documents. Neither would be required if I could organize my x-refs by nickname.
Then you should be pleased to know that we are working on adding sort order to both the documentation and xref views. Already have it working for docs, porting to xref now.
-
I have often taken string value (recipe names, recipe component names, etc.) broken them up into 16 bit values representing two bytes each, and transmitted them to a range of contiguous registers in the PLC.
When looking at the same range from the PLC end, in a DL PLC, you could add V2000 or whatever to a data view and configure it to display ASCII, x number of bytes, and byte swapped or not (IIRC).
You have all this and more for native DM strings, but in some cases I'm not doing anything with the strings, just keeping them in a block with associated operational data, so there's no reason to move them to an SS type value. In my case, they're in a range of MHR registers, which as far as I can see, I can only display as ASCII two bytes at a time.
Is there a way to emulate the old multi-register view for non string types in DM data views? If not, I'd like to make a feature request for it in a future release.
Thanks! ;D
-
Do-more meets DL half way (see the attached Data View screen shot). The numeric registers have ASCII and Swapped ASCII, but only for that register. But using Ctrl+Enter, you can easily monitor MHR/V/D/R,etc. as ASCII, addition to all the other Do-more numeric formats. The only thing you cannot do is specify the size - it's always the number of bytes for that numeric element (so you could get up to 4 characters per row using casts, e.g. MHR4:SD, vs. just two characters for MHR4).
-
Right, that's what I was saying, so consider it a feature request for whenever you have a chance to get to it.
At least showing the registers as 32-bit is twice as good as what I came up with.
Thanks! ;D
-
So those bytes stored in MHR's? I want to copy them to an SSx. The string in the MHR is variable length with no delimeter, and usually has zero's in any spare positions. I'm using STRPUTB to copy the bytes to the string. How do I strip the 0's when I copy to the SS? Alternatively, I'm using the SS to STRPRINT to another SS I'm going to STREAMOUT to something. Is there a way to strip the NULLs while doing the STRPRINT?
Also could really use the ability to EDIT numeric registers in multi-byte mode (extension of yesterday's request to be able to view them that way), or at least to be able to edit in ASCII one register at a time.
Tried STRTRIM but it only trims a list of about 6 common non-printing chars. Recommend adding a checkbox to have it delete ALL non-printing chars (or as customizable as you want to make it), but definitely with the capability to remove 0x00 bytes.
-
So those bytes stored in MHR's? I want to copy them to an SSx. The string in the MHR is variable length with no delimeter, and usually has zero's in any spare positions. I'm using STRPUTB to copy the bytes to the string. How do I strip the 0's when I copy to the SS? Alternatively, I'm using the SS to STRPRINT to another SS I'm going to STREAMOUT to something. Is there a way to strip the NULLs while doing the STRPRINT?
Also could really use the ability to EDIT numeric registers in multi-byte mode (extension of yesterday's request to be able to view them that way), or at least to be able to edit in ASCII one register at a time.
STRTRIM will remove leading or trailing whitespace, and it should remove NULLs as well...although I have a sinking feeling it may not. I will make sure it does for the upcoming release.
We have plans to add a memory view of the type you are asked for. It'll happen eventually.
-
I tried STRTRIM and unless I'm doing it wrong, it doesn't strip NULs.
Assuming that it doesn't, what's the workaround?
I tried STRFIND (to be followed with a STRDELETE), but I can't figure out how to enter a NUL as the character to find.
-
It's suppose to...and I just updated it to do so.
Workaround? Brute force. Loop...character by character...just like the instruction (now) does it.
-
But even then, I need a way to compare the byte in question to a NULL. How do I enter the string value for one to do the compare?
-
"$00"
-
Hmmm....thought I tried that in STRFIND. Maybe I didn't include the quotes. Will give it another try. (Because as long as I can find it, I can still trim it in two boxes with no looping)
-
STRFIND "$00" + STRDELETE works great.
You rock, dude! Thanks! ;D
-
Sorry it required the work around... ::)
-
No sweat. Consider it OJT in Do-More. ;D Heck, that's barely a workaround anyway!
One glitch -- STRFIND is edge triggered so it had only worked once when I reported it fixed. I'll need to generate some edges. Not a problem -- I have the technology! :D
-
That's now optional in rel 1.1. There were about 5 or 6 instructions that were strictly edge triggered that we have changed to optional.
-
To create an edge, I put an ST7 on the rung ahead of the STRFIND, but the rung is in a called program, and the scan toggle doesn't seem to work.
How should I handle edge triggered stuff in programs and tasks?
-
Still not retriggering the STRFIND despite the following logic. I can clearly see the timer recycling, so I don't know why the STRFIND isn't retriggering.
STRN T100.Done
TMR T100 100
STR T100.Done
INIT "3 MHR[V1] MHR[V1+9] 0"
STRGETB SS99 0 20 MHR[V1]
STRCLEAR SS100 1
STRPUTB SS100 0 20 MHR[V1]
STRN T100.Done
STRFIND SS100 0x4 D1 C34 ST1023 """$00"""
AND C34
STRDELETE SS100 D1 20
-
Not sure what you mean by "called program"....although I'm guessing you put it in a program block. The point is that they are not "called" per se, they are enabled to run.
-
Not sure what you mean by "called program"....although I'm guessing you put it in a program block. The point is that they are not "called" per se, they are enabled to run.
Yes, a program as opposed to a task.
-
Not sure what you mean by "called program"....although I'm guessing you put it in a program block. The point is that they are not "called" per se, they are enabled to run.
Yes, a program as opposed to a task.
If the program is running without exiting, it should work just fine. If it is exiting and rerunning, there are definitely edge considerations.
-
Edge triggered instructions, in my experience, are best implemented using a FOR/NEXT Loop.
FOR
V0
From 0
To 1
By 1
V0 = 1 ----------edge triggered instruction
NEXT
This is the simplest way (that always works) no matter where you place the instruction in your code.
-
Thanks, plcnut! ;D
-
Thanks, plcnut! ;D
I hate to admit it, but I stole the code from from Mark... So I guess we can both thank him ;D
Thanks Mark!
-
Thanks Mark!
You're welcome! However, we've addressed this issue in Designer Rel 1.1. STRFIND (plus STRPRINT, STRSUB, STRCMP, and DATAINFO) all now have the option to be Power-Flow enabled OR Edge-Triggered. You will need to upgrade your firmware too. See the attached screen shot of the new STRFIND editor.
-
Very cool! Any guess on release date?
-
Very cool! Any guess on release date?
We're in the Beta cycle, so all I can say is "soon".
-
If we hadn't continued to feature creep it, it would already be out. The problem is that we tend to actually listen to what y'all ask for... ;)
-
If the program is running without exiting, it should work just fine. If it is exiting and rerunning, there are definitely edge considerations.
Here's what ended up working well for me. The program containing the STRFIND does exit and is enabled periodically in $Main. The rung with the STRFIND has no real preconditions (begins with STR ST1), and it does appear to retrigger based on the performance of the STRDELETE that's using its output.
-
Also request a DL style tabular usage view for non-heap items. The tooltip Xref/usage is too limited in scope.
-
Also request a DL style tabular usage view for non-heap items. The tooltip Xref/usage is too limited in scope.
It's there. Cross reference view, usage mode.
-
It's under Tools now. Not sure why it was moved, but it really isn't a view in the truest sense, and I know some of that stuff got shuffled.
I use Ctrl+Y though...
-
Thanks!
-
Also, I miss the old-style database editor. I tend to plan memory allocation and enter a lot of the descriptions before entering ladder, especially for I/O. And the current smart view is awkward because it doesn't show all elements. It's much more efficient to use the table view then entering the elements one at a time and entering their descriptions. Or, just update the CSV import so it will do multi-columns to description lines like RSLogix does, and I promise I'll never use the internal one again (and therefore won't be harassing you about what it does or doesn't do).
-
The problem (or benefit, some would say) is that you can document everything...structs, struct fields, elements, casts, in a PLC that has many more times as much memory than DL controllers. The possible documentable things are virtually infinite. That isn't very efficient in a table.
But we did actually consider that folks might want to do it the old way. It isn't a perfect answer, but, it will get you most of the eay there...if you had started out doing it this way. If you will press the Add Record button on the Doc View, then enter an element, say X0, then hit the Enter key...it will add an empty reference to X0 and auto-increment. As many times as you hit Enter, it will create a new empty record for you. The one caveat is that once it increments to a record that exists in the database, the auto-increment no longer works,, so you have to manually enter the next location and hit Enter again.
-
Oh...one more thing. Those entries that have an asterisk next to the element are not actual database records and will be removed when the project is closed. So when you come back...they won't be there.
-
OK, that method sounds workable. One extra step, but in exchange for the huge advantages of DM, WELL worth it. Like you said, it would be almost impossible to do something so much more powerful and not have a small side effect here or there.
-
There was much discussion here. What about people who write code then document, people who document then write code, people who document while they code, etc? The conclusion was that as long as we provided a mechanism to approximate what was there before, the added benefit of being able to document "WX7:U" or "T3.Done" was far better than a honking huge table that many griped about already. The answer was to make it easy to insert stuff into the table. Perfect? No, but it kinda works one you know about it.
-
I sense continued benign neglect for those of us who like reverse video display... :o
Some of the lines in the Xref display (though at least not the most critical ones) are still black, even in reverse video, and correspond to none of the settings in the color setup as far as I can see.
The real issue, however, seems to be with printing. If you print not in B/W mode, it wants to print the ladder in white and other elements in the same bright colors as on the screen display, which is obviously not going to work. If you do print in B/W mode, you lose color differentiation for addresses, comments, etc., so that's already a sacrifice, but it doesn't seem to work anyway. I printed in B/W mode and one program printed accordingly, but the others reverted to color mode, so I can't print out ladder at all unless I revert to default color or (presumably) print out one program at a time.
What some (most?) other mfgrs do is allow printing colors to be configured separately from display colors.
PS. I still really dislike the roundtangles. On numeric points, the frame just wastes space, plus I don't like the shrunken font for both the element and status. On bits it's even worse, because you have the same disadvantages with no corresponding advantage (simultaneous display of address and value) to compensate. I'd rather just have both address and status in the same font as everything else and expand the box to accommodate.
I also had some weird situation where status was on and updating but wouldn't turn off, either with the status button or the No Status button (All Status and No Status: nice, BTW). I restarted Designer and it was OK. [shrug]
-
I'm sure we can touch up the colors issues. We'll make it work.
The element status thing is harder. We were trying to do a nice thing...giving you something you didn't have before...but honestly all it has done is invite complaint. The issue is that we are displaying two things in one cell. When you say "all you gotta do is..." you miss the bigger issue...there is no place to put it logically speaking...and to do so would require a significant rework to the display code...something we were trying not to do at this point. I don't guess I expect people to not complain, but the irony is that I don't know that I ever heard the complaint in DirectSoft, where we painted the status value only...no element or nickname. In an effort to fix a glaring problem, I guess we missed the mark and instead gave folks a new target. :-[
The truth is that we want to do a significant refactor of the display and editor at some time in the not too distant future...possibly Rel 2.0. When we do that, we definitely rethink status displays.
-
Right, I understand you have the internal architecture of your app to deal with and obviously I have no idea what the constraints are. I did dislike the status-only displays in DL and did complain about it, but I hate this. If I had to choose, and can't get both address and status in standard font, I'd rather go back to the old DL way. Not that I want to do that, it's just that's how much I dislike the current situation.
-
Interesting. Never would've guessed that anyone would opt for less info. Mark, can we make DL style status an option?
It may not help you, but you can choose the default type face to be larger. Some folks have done so and have been satisfied.
-
PS. I still really dislike the roundtangles. On numeric points, the frame just wastes space, plus I don't like the shrunken font for both the element and status. On bits it's even worse, because you have the same disadvantages with no corresponding advantage (simultaneous display of address and value) to compensate. I'd rather just have both address and status in the same font as everything else and expand the box to accommodate.
What is your zoom level? Try your zoom out to 125%. It's much more readable. I've had to do this with my IE browser - yes, I'm getting old. Also, I've seen this look bad on bad monitors, and better on good monitors. Let us know how 125% looks, if that is readable on your monitor.
-
Interesting. Never would've guessed that anyone would opt for less info. Mark, can we make DL style status an option?
Definitely - I'll look into it.
It may not help you, but you can choose the default type face to be larger. Some folks have done so and have been satisfied.
That is another option in addition to adjusting zooming level.
-
Was just playing with reverse video in 2D...definitely not optimal. We can and should do better. The whole color management thing really did not get any meaningful upgrade with Do-more. Again, we can and should do better.
One glaring problem is that cross reference is using the ladder display colors. In reverse video that works...um...poorly.
-
Interesting. Never would've guessed that anyone would opt for less info.
Not really opting for less info. I'd rather have two items I can read than one, but one I can read would still be more info than two that I can't, so in both cases the preference is actually for more rather than less
It may not help you, but you can choose the default type face to be larger. Some folks have done so and have been satisfied.
I haven't tried that, but it doesn't sound like it would work very well. If I get the address/status cells readable, then everything else is going to be vastly TOO big, I assume. I'll play with it and see how it works. I've tried the zoom percentage, which didn't help, but I'm not sure if that and font size are the same or not.
-
What is your zoom level? Try your zoom out to 125%. It's much more readable. I've had to do this with my IE browser - yes, I'm getting old. Also, I've seen this look bad on bad monitors, and better on good monitors. Let us know how 125% looks, if that is readable on your monitor.
I already tried 125%, and the combo cells are still illegible to barely legible on my laptop (15", 1920 x 1200, excellent quality), while the non-combo text is already starting to be unreasonably large (this is from memory -- can't go online at the moment).
-
One glaring problem is that cross reference is using the ladder display colors. In reverse video that works...um...poorly.
Believe it or not, BobO, the current Xref situation is the result of additional work that was done in response to my original griping several years ago, and it's better than it was before.
First of all, I don't agree that cross reference shouldn't follow ladder colors. If you've chosen foreground colors that contrast well with background colors for ladder, there's no reason they shouldn't work OK in Xref too. The lack of readability isn't because it's following those of my reverse video selections that it does, but rather the parts it come up with on its own.
The problem I was complaining about several years ago was that the Xref was halfway between following the ladder and not. Always white background, always black lines, but use the ladder colors for element, description, nickname. Not following would have worked. Following would have worked and looked better. Half following, not so much. Totally unusable in reverse video. So it got partially fixed, but some elements still didn't follow, like some of the lines still being always black instead of element-color. Not great, but I mentioned it at the time and then let it go.
-
Is it possible to rename a code block?
-
Is it possible to rename a code block?
User code-block as a Heap Item - yes. One of two ways.
1. Right click on the code-block in Project Browser in Edit mode, select "Configure Code Block". The Name: field should be editable.
2. Open the System Configuration dialog, Memory Configuration entry, select the Heap Item in the bottom list, hit the Edit Heap Item button, and again, the Name: field should be editable.
-
Thank you, Mark! :)
-
PS. I still really dislike the roundtangles. On numeric points, the frame just wastes space, plus I don't like the shrunken font for both the element and status. On bits it's even worse, because you have the same disadvantages with no corresponding advantage (simultaneous display of address and value) to compensate. I'd rather just have both address and status in the same font as everything else and expand the box to accommodate.
I forgot that we added this option to the October release of Designer (1.0.2). In the Ladder Options, UNcheck the Show Element Status in Bit Contacts and Coils box in the Misc. Options group. Don't forget to ALSO check the Apply options to: New Views check box. See the attached screen shot.
This will not help with relational contacts and boxes (they will still use round-tangles), but all your "discrete" logic will be readable and understandable w/STATUS ON.
-
That helps a lot (and declutters the screen besides). Thanks!
I'd eventually like to get to a place where I can see register address and status at the same time (and be able to read them), but for bits this is exactly what I want.
-
One glaring problem is that cross reference is using the ladder display colors. In reverse video that works...um...poorly.
Believe it or not, BobO, the current Xref situation is the result of additional work that was done in response to my original griping several years ago, and it's better than it was before.
First of all, I don't agree that cross reference shouldn't follow ladder colors. If you've chosen foreground colors that contrast well with background colors for ladder, there's no reason they shouldn't work OK in Xref too. The lack of readability isn't because it's following those of my reverse video selections that it does, but rather the parts it come up with on its own.
The problem I was complaining about several years ago was that the Xref was halfway between following the ladder and not. Always white background, always black lines, but use the ladder colors for element, description, nickname. Not following would have worked. Following would have worked and looked better. Half following, not so much. Totally unusable in reverse video. So it got partially fixed, but some elements still didn't follow, like some of the lines still being always black instead of element-color. Not great, but I mentioned it at the time and then let it go.
I don't disagree. We can and should make it right, at least for now. We may or may not be able to support DOS/retro displays indefinitely. There are things we'd like to do in the future that may start to conflict. No immediate knowledge of that, but it really starts to become cumbersome. The current issues are a great example of how this entropy sets in.
-
I can imagine the kind of dilemma you're foreseeing could certainly arise, and if you were willing to ditch reverse video to enable some new features, then I assume those features would be so compelling that it would be a good trade from the users point of view.
I don't think this is an illustrative case, though. Assuming I were going to allow the user to configure colors at all, then I would fix it so everything worked when they did so, without relying on any assumptions about what their choices were going to be. They made some of the colors in the Xref view follow the user choices, all they had to do was do that with all the colors and everything would have been hunky dory. Or, doing it like the docs view and ignoring all the settings would also have worked.
-
Like I said, I don't know of a problem at this point. Just be aware that it is already somewhat painful to maintain. Sometimes breaking with the past is necessary to embrace the future.
-
Understood. Really liking Do-More so far and can't wait to see what you guys add next! :)
-
Is there a way to create a terminal type window to monitor the traffic to and from a TCP or Modbus serial device?
-
Is there a way to create a terminal type window to monitor the traffic to and from a TCP or Modbus serial device?
For TCP, we use WireShark. It's a free utility that has configuration files for deciphering many "standard" application protocols, like SMTP or even Modbus. www.wireshark.org
For Serial, there are some utilities out there, but I haven't use any, and so I cannot recommend any. If there is a wireshark for serial ports, that would be awesome.
-
No, I've got stuff for PC based (recommend SysInternals PortMon among others for serial).
I'm talking about internal to Do-More. Say I'm talking to a servo or power supply or something and I need to troubleshoot the comms. How can I monitor the traffic via Designer?
-
You can use
STREAMIN/STREAMOUT to DmLogger device with whatever packets you want to monitor. That was one of the cool uses of DmLogger is a way to debug comm.
There is also a build-in mechanism to auto-log packets to DmLogger, but I think it is only implemented for the EMAIL instruction. Bring up the Debug View and press in the Message Dump button. BobO might know if there are any other instructions that support the "Message Dump" debug mechanism.
-
Actually everything written to either ERR or MSG is redirected to the logger port, but other than emails, that is mostly error information.
Of course with STREAMOUT and the logger device, it is very easy to roll your own diags.
-
DMLoggeris very handy, but it really needs some type of text wrap and/or horizontal scroll so I can view the whole string without exporting it. And also it would really be nice to be able to see the headers sent with TCP. While I'm at it... Could I somehow edit the header sent out over TCP?
-
We're happy to provide the source in either C++ or C#. You can mod it to your heart's content.
As for the header, there isn't one...it's just a standard UDP packet. In truth, the logger device itself is just a builtin UDP connection that hard codes the broadcast address and port 0x7272. You could do the same thing by manually creating one and doing a PACKETOUT. Anything else contained in the packet is put there by the networking stack.
-
DMLoggeris very handy, but it really needs some type of text wrap and/or horizontal scroll so I can view the whole string without exporting it.
The DmLogger app is resizable, and so the Message column will auto-resize to the full window size. You can also just maximize it.
And also it would really be nice to be able to see the headers sent with TCP. While I'm at it... Could I somehow edit the header sent out over TCP?
DmLogger is not WireShark, so it is not monitoring Do-more packets. The Do-more PLC DmLogger device actually sends out UDP "broadcasts" on port 0x7272. I think what you are wanting is to monitor actual packets to another device??? If so, that's what WireShark is great for.
-
I guess I'm showing my lack of understanding here ;) Where does the "200 OK" etc. part of the response header come from?
And again, the Logger is very handy(hope I didn't sound like I was complaining)!
-
That sounds like part of an EMAIL dump and has nothing to do with logger per se, it's just a part of the transaction with an SMTP server.
-
Trying to open a TCP connection to stream text to a remote PC, but can't seem to get OPENTCP to connect. I know the remote server is working because I've connected to it with other clients and streamed to it. Not sure what to troubleshoot next. Any ideas?
-
If all of the critical address/netmask/gateway stuff is correct, I would put Wireshark somewhere it can see the packets going both ways (hub or switch with monitor port) and see who sees what packets. In my experience this stuff works once everything is correct.
-
Well, in this case the other end of the wire is a Windows PC, so I can just load Wireshark on there. I'll be able to see if anything is showing up from the PLC or not, but if it is, I'm gonna have to send you guys the trace because I have no idea what a OPENTCP transaction is even supposed to look like when it works.
While I was typing that I wondered if there's a firewall active, but it lets me in from another PC, so I doubt that's it.
-
Trying to open a TCP connection to stream text to a remote PC, but can't seem to get OPENTCP to connect. I know the remote server is working because I've connected to it with other clients and streamed to it. Not sure what to troubleshoot next. Any ideas?
I've had this problem... But it was because I forgot to start WAMPServer on my PC ;)
-
[grins sheepishly]
When I first set up the device that I would stream to, I accidentally configured as TCP Server. I noticed it and reconfigured as TCP Client. Designer recognized that the heap item associated with the TCP server would be orphaned and said it was renaming it. I assumed then that everything was hunky dory, since it seemed to be aware of the issue and fixing it, but there must have still been a name conflict left over.
But, when I created a new device from scratch with a new name, then the bytes do appear in Wireshark on the receiving PC. For some reason they still are not showing up in the TCP server, but at least I know they made it to the PC, so I'll have to troubleshoot from that point on.
-
I'm trying to understand exactly what you did...
You created a server object named Fred.
Coded some stuff that referenced Fred.
Went back into the sysconfig and deleted Fred.
Then recreated Fred as a client.
Yes?
-
Darned if I can figure out what I did. I can't make it happen again. What I THOUGHT I did was this:
Created a new TCP server device named Fred
While still in the device creation dialog, noticed that I had made it a server.
Delete and recreate as a TCP Client.
At some point, when exiting the Device Config dialog, I think, I was warned that there was an orphaned heap item which would now be renamed to 'aFred' or something like that.
The recreated device showed as a client, which was the one that wouldn't open.
As soon as I created a new device from scratch with a new name, it immediately was able to connect (sure of this step)
So, for one thing, I don't think there was ever any ladder that addressed Fred while it was configured as a server.
-
aFred would only be created if an instruction was referencing ANY device called @Fred. If NO instruction referenced @Fred, then no unassigned nickname device aFred would have been created.
Could it be possible that you had previously created a device called Fred, then LATER went to create a NEW device, also called Fred - cuz we just fixed some bugs for Rel 1.1 that addressed duplicate device names.
-
I didn't think I had but I can't recreate it now, so I must have, if you say that's the only way it can occur. I just searched though, and didn't find anything that referenced aFred, but it could have been deleted along the way I guess.
-
That's why I was digging. I was having a hard time envisioning a scenario that would leave you with a busted device and still be able to download to the controller. If you had stumbled on a hole (you wouldn't be the first...just ask plcnut) I really wanted to know it before we release 1.1...very soon.
-
I didn't think I had but I can't recreate it now, so I must have, if you say that's the only way it can occur. I just searched though, and didn't find anything that referenced aFred, but it could have been deleted along the way I guess.
One possibility, if you generally tweak an online project (Simulator or PLC) without starting a new project or clearing the PLC, you will accumulate these interesting bread crumbs over time. So it could have been a tweak you made days ago that caused that unassigned device to show up (and remain) in your project.
-
One possibility, if you generally tweak an online project (Simulator or PLC) without starting a new project or clearing the PLC, you will accumulate these interesting bread crumbs over time. So it could have been a tweak you made days ago that caused that unassigned device to show up (and remain) in your project.
Mark, I do this all the time. I do a lot of online editing and only switch out of program 'run' mode when I have to. Also unless it's a brand new project, I don't clear memory.
Is this bad practice?
What "should" I be doing?
-
Mark, I do this all the time. I do a lot of online editing and only switch out of program 'run' mode when I have to. Also unless it's a brand new project, I don't clear memory.
Is this bad practice?
What "should" I be doing?
No, you're fine. I mean situations where you have your simulator that you "try things out". So it ends up being a collection or combination of different "projects" you've tried over the past 3 weeks. Last week it was a serial port named "Fred". This week it's a TCP Server named "Fred". Next week, it will be a CTRIO axis named "Fred", etc. etc.
Typical PLCs are targeted for a specific project that gradually builds.
Actually, both are fine. It's just, you may end up with an unassigned nickname from 2 months ago from some device you forgot you had "just to try" something out. We'll warn you, even let you know "replaced device @Fred with unassigned nickname aFred in instruction XYZZY at address 1234".
-
That's probably the culprit. Not so much stuff left in ladder as leftover devices and heap items. Initially I found the deletion of heap items a little non-intuitive (if it's a struct item corresponding to a device, for example, you can't delete the heap item, but must delete the device instead), and I'm just now emerging from the learning curve. It is the kind of thing I'd pay attention to, and I'll be more diligent about it now that my familiarity level with the process is increasing.
-
I think there may also be another problem, either in the way that I'm applying the instructions, or in the implementation of the server by the HMI software. Prior to rebuilding the device, nothing was showing received in Wireshark. When I switched to using the freshly-built never-a-server device, bytes started showing up in WS. Strings also began appearing in the HMI terminal window, but not consistently and with nothing like the frequency at which I was sending them.
So I suspect the HMI has some issues, or maybe how I'm using STEAMOUT, but I just don't have any more time to troubleshoot it, so since the PLC seems to be able to collect the data OK, I'm just going to store it locally and let the HMI fetch it. Problem is the STREAMIN from the polled device will now often exceed 64 characters, so how do I break that up into 64 byte strings?
-
Generally speaking, if the heap item is preceded with '$', it was created by the system, belongs to the system, and must be deleted by the system...generally implicitly by the counter operation to that which created it, in your case, the deletion of the device that used it.
The order of the system configuration pages is significant and there are dependencies. The CPU page can enable things that affect the I/O page. The I/O page contains things that need Module Configurations. Module configurations can create devices. Devices can create heap items.
Since devices can be created by the user or by module configs, some can be deleted by the user, but some must be deleted by changing or deleting the module config.
Since heap items can be created by devices or by the user, some can be deleted by the user, but some must be deleted by changes to devices, which might also be changes to module configurations.
It may not be intuitive, but it is specific and predictable once you understand the dependencies. Do-more isn't Click, but then again, I doubt you will be creating custom TCP protocols in Click.
-
I think there may also be another problem, either in the way that I'm applying the instructions, or in the implementation of the server by the HMI software. Prior to rebuilding the device, nothing was showing received in Wireshark. When I switched to using the freshly-built never-a-server device, bytes started showing up in WS. Strings also began appearing in the HMI terminal window, but not consistently and with nothing like the frequency at which I was sending them.
So I suspect the HMI has some issues, or maybe how I'm using STEAMOUT, but I just don't have any more time to troubleshoot it, so since the PLC seems to be able to collect the data OK, I'm just going to store it locally and let the HMI fetch it. Problem is the STREAMIN from the polled device will now often exceed 64 characters, so how do I break that up into 64 byte strings?
Who is limited to 64 byte strings? I don't understand the issue.
-
Right. That wasn't a complaint on my part, just an explanation of why I wasn't immediately proficient at it. I'm just about up to speed, like I had figured out that the $ meant system heap item and so on. I'd MUCH rather have the more powerful solution, despite the learning curve.
-
Who is limited to 64 byte strings? I don't understand the issue.
SSnnn.MaxLength shows as 64. On reflection, why would you make it a variable if it were a system limitation? I take it I can write to SSnnn.MaxLength?
UPDATE: OK, discovered SL's, but those also seem hard-limited to 256 bytes, and I might very well exceed that. Is there a larger or configurable string element, or we're back to my original question about breaking up the string among multiple elements (which is fine, I'm just asking how to do it).
-
Right. That wasn't a complaint on my part, just an explanation of why I wasn't immediately proficient at it. I'm just about up to speed, like I had figured out that the $ meant system heap item and so on. I'd MUCH rather have the more powerful solution, despite the learning curve.
There is definitely a learning curve for the most powerful features. Once the light turns on, however, you can do some stuff with this thing.
-
Use SL instead of SS, or better yet make your own String heap item or an array at 1024 Characters.
-
Who is limited to 64 byte strings? I don't understand the issue.
SSnnn.MaxLength shows as 64. On reflection, why would you make it a variable if it were a system limitation? I take it I can write to SSnnn.MaxLength?
A string is allocated to a particular length, that length is reflected in .MaxLength. Short strings (SS) are 64 bytes. Long strings (SL) are 256. You can allocate your own in heap or blocks of strings up to a MaxLength of 1024.
-
Use SL instead of SS, or better yet make your own String heap item or an array at 1024 Characters.
What he said.
-
Use SL instead of SS, or better yet make your own String heap item or an array at 1024 Characters.
Yeah, I'd discovered SL's in the meantime, but 256 bytes isn't going to cut it either. 1024 bytes in my own heap string should be fine, though.
Thank you both!! :)
-
I gotta do that training. A lot of this is non-obvious, but still basic enough that it would probably be covered. Review of all the data types and so on. Only problem is the time to do it. I HAVE noticed that I have 6 or 7 hours each night when no work's getting done, so.... :D
-
Do-more and Designer look enough like DL and DirectSoft on the surface to lull you into a false sense of adequacy. ;)
This is great in some ways and bad in others. It was designed to allow you to be immediately productive if coming from the DL/DSP bias...but...there is so much more there that you won't know about without either experience or education. I'm sure some will use Do-more without ever knowing, or needing, its full potential.
Like most, you are going through the Do-more change, where your preconceptions are slowing being dissolved and replaced by a strange sense of dependency on our new baby. Don't believe it? Just wait until you have to do something in DSP5 again...you'll see.
-
Do-more and Designer look enough like DL and DirectSoft on the surface to lull you into a false sense of adequacy. ;)
What an excellent line! :D
About getting attached to it, I know what you mean. Just ditching the BCD and octal alone is wonderful, let alone all the new features and the speed and memory capacity. AND being able to use SERIO's. That's been a boon on this particular project.
Shoot, about every tenth time I enter a numeric constant, I still enter a "K", and have to backspace over it!
-
Do-more and Designer look enough like DL and DirectSoft on the surface to lull you into a false sense of adequacy. ;)
What an excellent line! :D
All in fun of course...
-
Of course! ;)
-
Really liking the configurable memory! Thanks! :)
-
Feature request (unless there's already a way to do this that I don't know yet):
If you right-click on a task or program in the project browser, have in the context menu an option to jump to the enabling box(es).
BTW, CAN you have two boxes enabling the same program/task, or do you have to combine the logic in one rung with one box?
-
BTW, CAN you have two boxes enabling the same program/task, or do you have to combing the logic in one rung with one box?
You can enable in as many places as you want.
-
If you right-click on a task or program in the project browser, have in the context menu an option to jump to the enabling box(es).
With our new XRef database, that is easy. We can list out all the instances that use that code-block (e.g. RUN or ENTASK or HALT or SUSPEND or ???). Chances are, there will be only 1.
You can already do this using the XRef VIEW, but that requires navigating the XRef view to find the code-block element. We'll make it easier for you. ;D
-
I was wondering if it might already be covered in Xref. Just making that option that I mentioned jump to that spot in the Xref would be fine.
-
I was wondering if it might already be covered in Xref. Just making that option that I mentioned jump to that spot in the Xref would be fine.
Right click is your friend in Do-more. Context menu - what are all the things I can do from this code-block in the Project Browser?
Open it, go to the specific stage or rung in the tree, copy it into the clipboard (so I can paste it into another project or as of Rel 1.1 paste it in this project because I need to duplicate it for a similar device), delete it, configure it (e.g. rename), debug suspend/unsuspend, and soon, "show me where I enable/run this code-block from or where I HALT it or ..."
Ladder View has right-click/context menu. Doc Editor does. Data View does. Each pane in Launchpad will in Rel 1.1 (due out soon). Even the toolbar area does (to show/configure the various toolbars).
-
Thanks!!
I've noticed that I fairly frequently get into a situation where a Data view has stuff in the status column, but it isn't live. I can see the same points update in the ladder view, but they aren't changing in the Data View. If I hit "No Status" the stuff all clears, then if it hit "All Status" it starts refreshing again.
Is this something I'm doing or is a "feature"? :D
-
Is this something I'm doing or is a "feature"? :D
No. Sounds like somethings getting bogged down. We've addressed some of these issues back a while ago, but sounds like there are still some issues. :o
-
If I hit "No Status" the stuff all clears, then if it hit "All Status" it starts refreshing again.
And to extend Mark's thought...using "All Status" improves the chances of something getting bogged down...
-
If I hit "No Status" the stuff all clears, then if it hit "All Status" it starts refreshing again.
And to extend Mark's thought...using "All Status" improves the chances of something getting bogged down...
I still have this problem, even with only one Data View enabled.
-
I still have this problem, even with only one Data View enabled.
What are the specs on your PC?
-
I still have this problem, even with only one Data View enabled.
What are the specs on your PC?
Windows 7 Pro SP1
Toshiba Satellite P755
Intel Core i7-2670QM CPU @ 2.20GHz 2.20 GHz.
8.00 Gig RAM
64-bit OS
-
I also have only one data view open, but 10 or 12 ladder windows. Does having multiple ladder windows, even though only one displays, count in the bog factor?
-
I also have only one data view open, but 10 or 12 ladder windows. Does having multiple ladder windows, even though only one displays, count in the bog factor?
Status is being acquired on each open view, without regard to whether it is visible or not. Each view only acquires status on the portion of the view that would be visible were the view in the foreground. Generally, Do-more comms are plenty fast to keep up with all but the worst cases, although still finite.
My suspicion is that in some cases these are video driver issues, not comm issues.
-
In a related topic, I find I frequently refer to the status display of code blocks in the project browser. Excellent addition!! :)
Suggested enhancement: Vary status color by execution frequency. Like every scan vs. some scans vs. no recent scans. Or as much level of graduation as you want to do. Maybe some special type highlight for blocks that are yielding / time slicing.
I believe I saw for example, a block that was executing and exiting every cycle not highlighted.
-
My suspicion is that in some cases these are video driver issues, not comm issues.
Is the screen drawing code associated with Data Views the same as with DirectSoft? I didn't have any issues with Data views on the same machine with DS.
-
My suspicion is that in some cases these are video driver issues, not comm issues.
Is the screen drawing code associated with Data Views the same as with DirectSoft? I didn't have any issues with Data views on the same machine with DS.
Data view is virtually unchanged, as is the comm server. Biggest change is the ladder display, and the trend and project views.
-
Data view is virtually unchanged, as is the comm server. Biggest change is the ladder display, and the trend and project views.
OK, that's what I would have guessed based on the look. So does the same machine with same video adapter and driver working OK with DS but then having this issue with DMD weigh against it being a video driver issue?
Also, I'll also try with fewer ladder windows open and see if it still occurs.
Thanks!
-
OK, that's what I would have guessed based on the look. So does the same machine with same video adapter and driver working OK with DS but then having this issue with DMD weigh against it being a video driver issue?
Nope. Suggests it. The big change to the ladder view was to move away from raster drawing and over to all bitmap based drawing. Unless the data view is the only thing going, in which case I have no clue. The comm server is virtually unchanged, except to add the new protocol. Other than the ladder, trend, and project view drawing codes being pretty graphics heavy, the only other thing that has changes is that Do-more comms are far faster than DL, and as a result, we pump a whole lot more updates to screen...but now we have circled back to something related to video.
Hey Mark, what control do we now have of update rates?
-
Unless the data view is the only thing going, in which case I have no clue.
Haven't tried that yet. Don't normally work that way, obviously, plus it's intermittent, so it might be a while before I could test that.
-
We have some inside information that Rel 1.1 Beta addresses this issue. Data View is updating some rather large data sets w/22 1024 byte strings.
-
We have some inside information that Rel 1.1 Beta addresses this issue. Data View is updating some rather large data sets w/22 1024 byte strings.
Cool!
Another code block related feature request -- add to right-click menu ability to start or stop a program, possibly even enable a task.
-
We have some inside information that Rel 1.1 Beta addresses this issue. Data View is updating some rather large data sets w/22 1024 byte strings.
Is there text wrap for the really long strings?
-
Is there text wrap for the really long strings?
Just change the display format. Look here for details
http://forum.hosteng.com/index.php/topic,1128.0.html
-
Another code block related feature request -- add to right-click menu ability to start or stop a program, possibly even enable a task.
+1
This would be super helpful!
-
Another code block related feature request -- add to right-click menu ability to start or stop a program, possibly even enable a task.
+1
This would be super helpful!
This is hard-ish. Stages control their state internally, but programs and tasks work very closely with their enabling instruction. It isn't impossible, but it isn't particularly straightforward either. Of the requests, running and stopping a program would be the easiest. Tasks would be considerably harder.
-
Actually just looking at the effort on the program run/exit...it would be pretty easy. Task is still difficult though.
-
This is hard-ish. Stages control their state internally, but programs and tasks work very closely with their enabling instruction. It isn't impossible, but it isn't particularly straightforward either. Of the requests, running and stopping a program would be the easiest. Tasks would be considerably harder.
I tend to think the ability would be less useful with tasks anyway. Seems a more natural fit for the way programs are normally enabled. Turning them OFF would be trickier but I think there's already a mechanism for aborting from the outside so this would have to tie into that and work the same way that does I guess.
-
Actually just looking at the effort on the program run/exit...it would be pretty easy. Task is still difficult though.
That's OK. 80/20 situation -- the easy one gets you the majority of the function anyway.
-
This is hard-ish. Stages control their state internally, but programs and tasks work very closely with their enabling instruction. It isn't impossible, but it isn't particularly straightforward either. Of the requests, running and stopping a program would be the easiest. Tasks would be considerably harder.
I tend to think the ability would be less useful with tasks anyway. Seems a more natural fit for the way programs are normally enabled. Turning them OFF would be trickier but I think there's already a mechanism for aborting from the outside so this would have to tie into that and work the same way that does I guess.
Mark and I were just chuckling about the fact that your opinion on the importance of tasks vs programs strongly implied that you were using them both correctly!!
I just finished writing the code to run and halt programs, as well as enable a task once...basically the edge triggered version. No reason we shouldn't get it into 1.1.
-
I agree on the importance of Program control vs. Task control. I don't think I've had a need yet to disable a task from the UI, but especially on a Stage only Program when I've accidentally transitioned to a non-existent stage and have to write code to disable the Program externally. ::)
-
Mark and I were just chuckling about the fact that your opinion on the importance of tasks vs programs strongly implied that you were using them both correctly!!
Woo hoo! You knew the light would come on eventually, didn't ya? :D
I just finished writing the code to run and halt programs, as well as enable a task once...basically the edge triggered version. No reason we shouldn't get it into 1.1.
Thank you! That was the very best case of what I hoped would be feasible.
-
Just change the display format. Look here for details
http://forum.hosteng.com/index.php/topic,1128.0.html
Not so much. What I was envisioning was a pure ASCII display (either your "ASCII" or "Quoted" modes is fine) with wrap. Yes, I can get wrap by choosing a HEX mode, but then it takes 75% of the column width for the hex version of the display, which isn't what you want when the original issue is that the string is very long. What HEX mode gives with one hand it takes away with the other.
So, feature request for wrap on ASCII and/or Quoted formats.
-
I think you guys (Host) are experiencing "give us an inch and we'll take a mile" on this one. The Text/communications power that Do-more provides necessitates greater viewing/editing of Strings. It would be really nice to have a Copy/Paste field to view and edit even the largest Strings in run mode without doing a program update.
BUT I for one am very willing to be patient on this one realizing how much you guys have(are) put(ting) into this controller.
-
Oh yeah, me too. I don't mean to sound crabby, just clarifying what I think probably wasn't clear in my previous post. And yes, it does seem weird after all the stuff they've packed in to be asking for even more.
-
We are neither surprised nor offended that you ask for stuff. Truth is that you wouldn't ask unless you believed that we could and we would. I take it as a compliment that you care enough to ask and have the confidence that will do something about it.
-
That's exactly the confidence I have. Still getting used to learning by observation how edges and other conditions are viewed by programs, but I'll get there.
Loving DM! Just completing my first project in it and besides the stuff that was just easier to write than a DL there are several items you just could not do, period. Custom protocol TCP comms, multiple-port Modbus RTU with SERIO cards, etc. Thank you!
-
Still getting used to learning by observation how edges and other conditions are viewed by programs, but I'll get there.
Some of the string processing stuff most associated with custom comm was made edge triggered unnecessarily. We've fixed that in 1.1, where we've made them optional. We created some situations with edge triggering that are just...well...hard. Easily our biggest mistake of 1.0 and proves that no matter how much you get right, you're only one lapse of judgement from a mess. The good news is it wasn't hard to fix. The bad news is that otherwise simple stuff got hard...and some of you early adopters paid the price in confusion. ::)
-
I think what was non-intuitive for me was the interaction of edge-sensitivity when placing edge-triggered instructions in non-continuous code-blocks. That's why I was saying "programs"; trying to figure out how an edge triggered instruction would work when inside a non-$Main block and what method was appropriate for generating edges in that context.
Anyway, like I said, I'm still working my way up the learning curve, but boy is it worth it!
-
I think what was non-intuitive for me was the interaction of edge-sensitivity when placing edge-triggered instructions in non-continuous code-blocks. That's why I was saying "programs"; trying to figure out how an edge triggered instruction would work when inside a non-$Main block and what method was appropriate for generating edges in that context.
Another key distinction between tasks and programs, and no doubt a driving force behind you arriving at the proper use of each. Programs are continuous when running, so edge behavior is just like $Main...which is in fact just a program that we start automatically and don't let terminate. Tasks and edges can work too, but tasks don't have to be continuous and can cause all manner of confusion when they are not. This is why the program check will warn you in certain cases.
Do-more definitely has a learning curve when you wish to venture beyond basic ladders in $Main, but as I think you have found, the rules do make reasonable sense once you understand what is going on and why. And the payback is well worth the effort to learn, which I think you have also discovered. ;)
I'll admit it, I'm pretty smitten with this controller, and I guess am pretty insufferable as a product papa. But I can tell you this is waaay more fun than constantly making excuses for a bad product. ;D
-
I'll admit it, I'm pretty smitten with this controller, and I guess am pretty insufferable as a product papa. But I can tell you this is waaay more fun than constantly making excuses for a bad product. ;D
Having spent two day just getting an AB Compactlogix programmed as a backup and I had the program already, just shows how much better the Do-More is! You can't even go on AB web site and look for info without a "TechConnect" contract. I just love the fact you do not have to have a dozen program activations to use designer. We do a lot of in house control work and we use AD for everything that is possible. As the senior control engineer here I told everyone to use Do-Mores on all new projects except small projects that will get Clicks. Main reason free software that does not have actiction that has caused more problem than we have ever had from all AD products we have used.
Is there plans for things like DeviceNet scanners for the Do-More? I could then get rid of a few CompactLogix PLCs using DeviceNet for all I/O that came in on some equipment we bought. I'm fixing to have to make some major changes to the programs and be a great time to can them ;D
-
Is there plans for things like DeviceNet scanners for the Do-More? I could then get rid of a few CompactLogix PLCs using DeviceNet for all I/O that came in on some equipment we bought. I'm fixing to have to make some major changes to the programs and be a great time to can them ;D
Sorry, no immediate plans. For the next bit, we will be adding the features...lots of good stuff coming, and then adding new platforms. Once we are to a reasonable feature set on a good range of hardware, we'd like to start looking at enhancing comms and see if we can go after some more competitive jobs.
-
Programs are continuous when running, so edge behavior is just like $Main...which is in fact just a program that we start automatically and don't let terminate. Tasks and edges can work too, but tasks don't have to be continuous and can cause all manner of confusion when they are not. This is why the program check will warn you in certain cases.
Well, so far my choice between using programs vs. tasks is usually guided by the termination style and the nature of what it’s doing. I’m inclined to want to use the word “task” here to describe the job for the code block, but that would be confusing, so I’ll call it a Thing To Do (TTD). If it’s finite in scope, the completion condition is internal to the TTD, and I’d like to launch it in a fire-and-forget mode, then the self-terminating nature of programs seems like a good fit. If it’s some continuous but low priority TTD like scaling analog inputs or something, time slicing in other words, then a periodic yielding task seems to be a good fit (yielding continuous program would work here too). Feel free to revise your previous attitude that I've grasped the program vs. task concept. ;D
So I do end up using programs on TTD’s that are recurring but not periodic nor continuous low-priority. "When situation X occurs, fire program Y." So then when I talk about edges, one shots, etc., as they’re perceived in programs I’m not talking about how they work during one long or continuous operation (like $Main works), but how they span the first scans of multiple invocations.
You could come up with several mental models of how this might be implemented.
- VLS: Very long scan. The code will react as if it’s being executed synchronously with the “main” block of ladder but just with a very long scan time, seconds even.
- JMP: Somewhat like a DL-Classic subroutine, or more properly, like a chunk of ladder after the end of the rest of the ladder (because they don’t branch immediately), enabled with a bit and a JMP, and you’re setting the bit in the regular continuous portion of the ladder. Only SETting it, though, and the code block must RST it, even if it executes on several scans before doing so. (A task would be the same, except the enabling coil is an OUT, and disabling is the inverse condition of enabling and handled at the same location, rather than in a pitch/catch fashion like programs.) Edges will only be detected if it’s an edge on that particular scan of the main program.
- PTR: The same things that would generate an edge in $Main subsequent to a Program-to-Run transition will generate an edge on the first scan of a program. IOW, the code block will run like A $Main but not with any reference to THE $Main.
My initial instinct before experimenting was to assume the PTR model and for the most part that does turn out to be the best model. Here’s the summary of what I learned by trial and error and observation.
- Timers reset on first scan (which isn’t bad, but slightly weird because timer ACCs are now retentive in $Main unless you make them non-retentive or enable them with STRN ST0, so this mimics DL-Classic PTR behavior but not Do-More $Main PTR).
- One shots contacts, both bit and inline, are triggered on first scan, even if the event occurred many $Main scans ago.
- System bits (STx's) are interpreted as they would be in $Main at that same instant (because it’s a reference to a literal CPU memory location, so how could they not?). For example, a rung enabled with ST7 in a program written to execute once and then terminate, neither always works nor always not, implying that it’s ST7 exactly as would be seen by $Main during the same scan. Same with ST0.
- Edge triggered instructions, at least sometimes, are triggered on each execution of a program, even if enabled with STR ST1. (This is weird because I had some edge triggered instructions in a program that appeared correct but wouldn’t work in ways that looked like edge triggering issues. I moved the rung to $Main verbatim at ADC’s suggestion and it worked fine. [shrug])
My reason for posting is as a guide to other DM newbies, and so you can correct any misconceptions, so correct away!
-
Well, so far my choice between using programs vs. tasks is usually guided by the termination style and the nature of what it’s doing. I’m inclined to want to use the word “task” here to describe the job for the code block, but that would be confusing, so I’ll call it a Thing To Do (TTD). If it’s finite in scope, the completion condition is internal to the TTD, and I’d like to launch it in a fire-and-forget mode, then the self-terminating nature of programs seems like a good fit. If it’s some continuous but low priority TTD like scaling analog inputs or something, time slicing in other words, then a periodic yielding task seems to be a good fit (yielding continuous program would work here too). Feel free to revise your previous attitude that I've grasped the program vs. task concept. ;D
No, that about sums it up.
So I do end up using programs on TTD’s that are recurring but not periodic nor continuous low-priority. "When situation X occurs, fire program Y." So then when I talk about edges, one shots, etc., as they’re perceived in programs I’m not talking about how they work during one long or continuous operation (like $Main works), but how they span the first scans of multiple invocations.
You could come up with several mental models of how this might be implemented.
- VLS: Very long scan. The code will react as if it’s being executed synchronously with the “main” block of ladder but just with a very long scan time, seconds even.
- JMP: Somewhat like a DL-Classic subroutine, or more properly, like a chunk of ladder after the end of the rest of the ladder (because they don’t branch immediately), enabled with a bit and a JMP, and you’re setting the bit in the regular continuous portion of the ladder. Only SETting it, though, and the code block must RST it, even if it executes on several scans before doing so. (A task would be the same, except the enabling coil is an OUT, and disabling is the inverse condition of enabling and handled at the same location, rather than in a pitch/catch fashion like programs.) Edges will only be detected if it’s an edge on that particular scan of the main program.
- PTR: The same things that would generate an edge in $Main subsequent to a Program-to-Run transition will generate an edge on the first scan of a program. IOW, the code block will run like A $Main but not with any reference to THE $Main.
I think PTR is the best model, but maybe it would be helpful if I give you a glimpse under the covers. Every edge has a hidden bit in the image register that contains the prior state of the associated bit, and is initialized to zero by the Do-more engine. Simply put, an edge is defined by the prior state being low and the current state being high, as viewed by the instruction itself. The other key point is that edge bits are re-initialized to zero any time instruction block or stage termination is run.
- Timers reset on first scan (which isn’t bad, but slightly weird because timer ACCs are now retentive in $Main unless you make them non-retentive or enable them with STRN ST0, so this mimics DL-Classic PTR behavior but not Do-More $Main PTR).
They actually reset on termination, the first scan after the block is 'done'. We have a case to add an option to ATMR to not reset on termination. Sounds like that would fit you.
- One shots contacts, both bit and inline, are triggered on first scan, even if the event occurred many $Main scans ago.
Yes. The only exception is counter inputs.
- System bits (STx's) are interpreted as they would be in $Main at that same instant (because it’s a reference to a literal CPU memory location, so how could they not?). For example, a rung enabled with ST7 in a program written to execute once and then terminate, neither always works nor always not, implying that it’s ST7 exactly as would be seen by $Main during the same scan. Same with ST0.
Yes, the ST locations are global image register managed by the system, independently of the task or program they are referenced from. They are not timers, per se, but can be used to control time based behaviors. For timed operations within a program, use a timer. In using a timer in this way, the need for termination upon completion starts to make sense.
- Edge triggered instructions, at least sometimes, are triggered on each execution of a program, even if enabled with STR ST1. (This is weird because I had some edge triggered instructions in a program that appeared correct but wouldn’t work in ways that looked like edge triggering issues. I moved the rung to $Main verbatim at ADC’s suggestion and it worked fine. [shrug])
There was a bug in 1.0 in tasks, where a completion and re-enabling of a one-shot task within the same scan would not run termination, resulting in busted edges. It's fixed for 1.1. Other than that, edges should work as expected and will always fire on each RUN or ENTASK, and reset on the termination scan after each completion.
-
I found a soluntion for the DeviceNet connection issue, Turck has a BL67-GW-EN-DN a modbus TCP to DeviceNet Gateway 8) I found one on line for $502.74. They make some other gateway too, all IP67 Rated.
-
I didn't know Turck made gateways. Good to know. And $500 a pop is a steal. Most of the Prosoft stuff, for example is in the $1500 and up range.
-
$1500? I'm in the wrong business...
-
Yeah, I know. :( Kinda hard to part with $[3 PLCs] for a protocol gateway. And $1500 is nothing; I think one I priced recently was like $2800 or something. (Compact Logix in-rack Modbus TCP master. Course any module that's AB in-rack, a lot of the cost comes from the AB vig.)
-
Thank you so much for the Datainfo blocks and parameterizing everything. I have just transformed hundreds of pages of code into 1.5 pages and a handful of memory blocks.
-
Thank you so much for the Datainfo blocks and parameterizing everything. I have just transformed hundreds of pages of code into 1.5 pages and a handful of memory blocks.
Sweet!
-
Is there a way to reserve a chunk of memory so that it won't show up in "the next available element" of the nickname assigner?
Example: SET: C[V0] where V0 could be 0 through 9. I can use MEMCLEAR or INIT for this range and it will then show up as used in the xref usage mode, but how do I eliminate it from showing up in the nickname assigner?
-
Some "auxiliary" windows such as XRef default to a horizontal docked position. I tend not to like this as it steals screen real estate from ladder. Now the window can be undocked and/or dragged over and docked on the side like DirectSoft (which always felt like an annoying compromise anyway vs. just allowing them all to be full screen), but the new XRef view has a lot more information, so it doesn't act like a very good citizen in a tall narrow view.
The most important columns the way I work/think are the first and fifth, followed by the fourth, followed by the third. So I'd like to be able to rearrange the column order, stretch the width (preferably all the way to zero), and/or hide and unhide specific columns. It seems almost necessary to make it useful in a vertical format at a reasonable percentage of screen width, but none of those are options. I suspect it was made draggable/dockable, but none of the developers uses it on the side. (Or perhaps has a really wide monitor).
CORRECTION: You can stretch the column widths, but the already-too-wide default width is the minimum for many of the columns.
So, feature request: Configurable columns in XRef. Some combination of draggable order, width adjustable to much smaller values or zero, and hide/unhide.
BTW, the filter buttons for IN, OUT, IN/OUT: very cool!
-
Is there a way to reserve a chunk of memory so that it won't show up in "the next available element" of the nickname assigner?
Example: SET: C[V0] where V0 could be 0 through 9. I can use MEMCLEAR or INIT for this range and it will then show up as used in the xref usage mode, but how do I eliminate it from showing up in the nickname assigner?
There's not a way to do it, but I understand the need. For now, I would probably create different blocks for things I intended to treat that way.
-
Is there a way to reserve a chunk of memory so that it won't show up in "the next available element" of the nickname assigner?
Example: SET: C[V0] where V0 could be 0 through 9. I can use MEMCLEAR or INIT for this range and it will then show up as used in the xref usage mode, but how do I eliminate it from showing up in the nickname assigner?
There's not a way to do it, but I understand the need. For now, I would probably create different blocks for things I intended to treat that way.
I guess I could just give them nicknames, that would get them out of the list ;)
-
Some "auxiliary" windows such as XRef default to a horizontal docked position. I tend not to like this as it steals screen real estate from ladder. Now the window can be undocked and/or dragged over and docked on the side like DirectSoft (which always felt like an annoying compromise anyway vs. just allowing them all to be full screen), but the new XRef view has a lot more information, so it doesn't act like a very good citizen in a tall narrow view.
The most important columns the way I work/think are the first and fifth, followed by the fourth, followed by the third. So I'd like to be able to rearrange the column order, stretch the width (preferably all the way to zero), and/or hide and unhide specific columns. It seems almost necessary to make it useful in a vertical format at a reasonable percentage of screen width, but none of those are options. I suspect it was made draggable/dockable, but none of the developers uses it on the side. (Or perhaps has a really wide monitor).
CORRECTION: You can stretch the column widths, but the already-too-wide default width is the minimum for many of the columns.
So, feature request: Configurable columns in XRef. Some combination of draggable order, width adjustable to much smaller values or zero, and hide/unhide.
BTW, the filter buttons for IN, OUT, IN/OUT: very cool!
We have plans to create what we are calling 'super view' that would be a fully configurable Xref/Doc/Data/Etc view. Not sure of the schedule for it, but we feel that may be a better plan than trying to fix all of the existing views. Improving the configurability of the Xref view probably wouldn't be too hard though, so we might look at that for a future release.
-
Is there a way to reserve a chunk of memory so that it won't show up in "the next available element" of the nickname assigner?
Example: SET: C[V0] where V0 could be 0 through 9. I can use MEMCLEAR or INIT for this range and it will then show up as used in the xref usage mode, but how do I eliminate it from showing up in the nickname assigner?
There's not a way to do it, but I understand the need. For now, I would probably create different blocks for things I intended to treat that way.
I guess I could just give them nicknames, that would get them out of the list ;)
Yep...that'd work to. Sometimes the simplest answers are the best. ;D
-
We have plans to create what we are calling 'super view' that would be a fully configurable Xref/Doc/Data/Etc view. Not sure of the schedule for it, but we feel that may be a better plan than trying to fix all of the existing views. Improving the configurability of the Xref view probably wouldn't be too hard though, so we might look at that for a future release.
Thanks for both efforts (upgrading XRef and the cool sounding super view)!
Rereading my posts, I realized it might have sounded like I wanted to rearrange the columns just so they'd be in my perceived order of importance, but that's not what I meant. What I was saying was that if I have a certain budget of screen width for the stuff docked on the left, I'd keep adding columns going down that list till I got to the limit of what would fit in the allowed total width at a readable zoom level.
-
Did you know that all dockable/floatable can be auto-hidden? Just "unpin" the dockable/floatable (the pin button next to the X close button in its title bar).
When it's in this mode, you can make it occupy as much of the client area as you want, and then float your cursor on top of its "tab". It will pop up and even stay there as long as your mouse cursor stays over that view. It will auto-hide once you move your cursor away.
If you click on the unpinned but docked view (giving it focus), it will stay "exposed" until you give focus to another view (e.g. Ladder View or another dockable/floatable).
What's great about this is that your client area (where your Ladder view sits) is maximized, and those views are not even a mouse click away (just a float your cursor away)!
We try to make most dockable/floatable start docked on the left (this is actually configurable in Global Options on left or right side). However, XRef, Output, and Find Results, which are wide, always start on the bottom. If I ever need one of those views, but need my Ladder View to stay as large as possible, I "unpin" it (I do this sometimes with the Project Browser/Launch Pad on the left).
-
I have tried unpinning while having all the stuff docked on the left. It was okay; I wasn't wild about it. (I almost never auto-hide the Windows taskbar for example, though I do like to hide the Office start bar) I don't mind the output and find results windows on the bottom because I don't tend to keep them open more than momentarily. The XRef I'll keep up for at least several minutes (or even "on" but stacked with other stuff on the left till I close Designer).
I haven't actually tried auto-hiding on the bottom yet, and I will. I'm just used to having it on the left and it should still be able to be with some of the updates I mentioned before.
OTOH, the new super view might obsolete all these other views so I can't wait to try that once you guys can get to it.
Also, the table Data View (or "memory dump") view pretty much has to be full screen (or at least as full screen as the ladder view) to be of any benefit, so when you get that done, it will have an effect on this issue as well. The "AB way" for that is not to have any separate screen real estate or keystrokes dedicated to editing, you just click on the register you want to edit (or arrow from a previous cursor location) and enter the new value. <Enter> will write and keep the same register highlighted; arrowing writes and moves the cursor with no other keystrokes/confirmation required. I haven't killed anybody yet with it.
-
My 2p here is that a customized data view would be GREAT and very valuable from a troubleshooting point of view. One of the largest considerations I have with streamlining and making this code more modular is that it is still readable. For example, while Loops and array are great from a code WRITING standpoint, when you are troubleshooting something, they are a big PIA. I've built in troubleshooting view loops, but it would be better if I could see data in two dimensions, i.e. blocks next to each other, where the rows correspond to one another. Or something customizable. Because this is such an important consideration, I've considered writing something like this into the HMI just to make it available to the engineer/technician who will need to poke around.
-
Big kudos on Force/Unforce in the right-click menu! Much more convenient the old UI. :)
-
My 2p here is that a customized data view would be GREAT and very valuable from a troubleshooting point of view. One of the largest considerations I have with streamlining and making this code more modular is that it is still readable. For example, while Loops and array are great from a code WRITING standpoint, when you are troubleshooting something, they are a big PIA. I've built in troubleshooting view loops, but it would be better if I could see data in two dimensions, i.e. blocks next to each other, where the rows correspond to one another. Or something customizable. Because this is such an important consideration, I've considered writing something like this into the HMI just to make it available to the engineer/technician who will need to poke around.
As a work-around, note that since Data Views are dockable/floatable, you can stack them next to each other to give you a 2D layout (see attached screen shot). They can be floated as a group also (great if you have a 2nd monitor).
-
When doing a cross reference for a bit-of-word, say D1000:12, all the references to that upper level element, in this case D1000, are listed in one group, sorted by location, so you get D1000:15 inputs and outputs mixed in with the :12 ones and so on.
For me I think it would be much more helpful if each bit got its own display group and label in the left column, or at least if still grouped by word/dword, that they were sorted by bit first and then by location. All the :0's first sorted by location, then all the :1's and so on.
If in separate groups, I'd have the D1000 native sized group first, then D1000:0, D1000:1 and so on.
-
I understand the request and I could possibly do something in the new sorts. The problem is that the extra information you are wanting to sort is pretty complex and can be the full range of casts, as well as struct fields. I currently have the block name sort sorting those fields alphabetically, but that isn't going to give you what you want.
-
Hmmm. So you're saying there is a sort option that goes D0, D0:0, D0:1, D0:10...D0:19, D0:2, D0:20...D0:29, etc?
I don't really like when numeric stuff gets sorted alphabetically like that, but it does give me a lot of what I want which is the bits separately, rather than mixed.
Is this in the production release already and I'm not aware of it, or is it in v1.1?
I do see what you mean about all the potential casts complicating things. I don't know about everybody else, but I'd be happy with native size plus bit level as separate groups, without any other casts (or with the other casts thrown in with the native group. I use other casts less commonly than bit-of-word, or at least I have in the past.
-
Hmmm. So you're saying there is a sort option that goes D0, D0:0, D0:1, D0:10...D0:19, D0:2, D0:20...D0:29, etc?
Is this in the production release already and I'm not aware of it, or is it in v1.1?
Yes. Was added for 1.1 in response to user requests.
-
Gut enough? Ja?
-
Very Good! ;D
-
Gut enough? Ja?
Ja, SEHR gut, danke! Viel spass! ;D
-
Gut enough? Ja?
Ja, SEHR gut, danke! Viel spass! ;D
I know a little German...
https://www.youtube.com/watch?v=L0lJyDCLYTE
-
Also added expansion of simple ranges. Might have already mentioned that, but don't think I posted pics. Note C0 through C10...
-
Also added expansion of simple ranges. Might have already mentioned that, but don't think I posted pics. Note C0 through C10...
That's VERY cool -- kudos! :o
-
Also added expansion of simple ranges. Might have already mentioned that, but don't think I posted pics. Note C0 through C10...
That's VERY cool -- kudos! :o
The compromise that allowed it to happen was making it optional and limiting it to simple types (C0-C100 vs D0:12-D10:31). The 'Ex' button toggles it on and off, and the default can be set in 'Options...'. For you guys that use this stuff reasonably, it will work just fine. And for the folks that do fringe stuff, it can be turned off for performance.
-
Let me say that the Do-More PLC is a big jump over the DL205. The ability to costume the memory, use of nicknames, Programs and Tasks, faster timers (1/1000 of a second), PID view to name a few of the many features. What I really like are the System Tasks. I have been using the $TopOfScan and $BottomOfScan to add in ladder logic that emulates my actual hardware with no I/O pluged in (just the Do-More processor and a C-more display). I just configure simulator memory for the Vs, Cs, and Ts that I need to emulate the equipment and can run the program logic as if it were the actual equipment. Of course the simulation part has to by correct to work right.
Only complaint is the memory size limit on strings. I need 26 4k strings for the next part of the project upgrade. Maybe if you came out with a memory expansion module with a few megs of memory.
Good work guys!
PS! Need an option for XRef to switch between instruction address to rung address.
-
Love the Do-more. Wish it fit my 405 chassis w/ 450s. It would be nice if the Trending was taken one step further and could sample at 1/sec, 1/min, etc. and record all my PLC data in column format with a time stamp. That way I could get rid of LABView's Industrial Process Monitoring and OPC servers and all the hassle for data acquisition. It seems that the current Trend view is pretty close to a full blown data acquisition system. Just needs a user adjustable sample rate and formatting.
-
Love the Do-more. Wish it fit my 405 chassis w/ 450s. It would be nice if the Trending was taken one step further and could sample at 1/sec, 1/min, etc. and record all my PLC data in column format with a time stamp. That way I could get rid of LABView's Industrial Process Monitoring and OPC servers and all the hassle for data acquisition. It seems that the current Trend view is pretty close to a full blown data acquisition system. Just needs a user adjustable sample rate and formatting.
DL405 is a hard thing due to it being very mature. We do get occasional requests though, all retrofit. Makes me wonder how much is out there, but still pretty afraid of doing a design in search of a market.
The trend view idea sounds pretty useful. For a possible near term workaround, look into DMLogger. You can use a STREAMOUT instruction on the @DMLogger device to push data into the DMLogger app (DmLogger.exe in your Bin directory) which you can save to a file. We also have the source available for the app, so it can be modified to do whatever you want.
-
Wouldn't mind seeing a 405 SIZED system (16-pt I/O modules with big terminals, 32-pt maybe with small terminals, and 32- and 64-pt using connectors).
That's been a popular form factor for a lot of PLC manufacturers over the last 20-25 years.
But to reuse the 405 itself at this date? Nah.
-
With the footprint of that beast, you could probably put in a 205 Domore and might still have room for the Ziplinks with angled brackets.
-
BOB: "DL405 is a hard thing due to it being very mature. We do get occasional requests though, all retrofit. Makes me wonder how much is out there, but still pretty afraid of doing a design in search of a market."
The DL405 being very mature means there are a lot of systems out there. If companies could upgrade the 405 chassis with the Do-more brain it would be a win/win. They can use the existing 405 modules which handle higher current/channel counts and not have to re-wire existing systems. Also, for engine/gearbox testing we use the F4-08MPI for measuring RPMs from hall effect sensors (magnetic pickups). With such a tiny milli-volt signal you can't use the CTRIO for RPM measurement, thus the 405. We are still buying 405s. I believe a lot of companies would buy new 405s with a Do-more brain for the processing power, high current/channel count and ease of wiring. There has got to be a ton of existing 405s that would love a new brain! We sure would.
BOB: "The trend view idea sounds pretty useful. For a possible near term workaround, look into DMLogger. You can use a STREAMOUT instruction on the @DMLogger device to push data into the DMLogger app (DmLogger.exe in your Bin directory) which you can save to a file. We also have the source available for the app, so it can be modified to do whatever you want."
The DMLogger formats all the data from multiple channels in one column. Data acquisition systems have the channel data in separate columns across the top and a time stamp along the side. Also, DMLogger is limited to 10000 records. We record data 24/7 for some tests. If you could e-mail me the source code, I would like to at least look at it and see if anything could be done.
Man, the Trend View is awesome...it is soooo close to being a great data acquisition system...just needs a button to select the sample rate and the format of each channel across the top in columns (with a nickname column header) and the time stamp along the side.
Thanks for your awesome products and service. ttK (to the King!)
-
BobO,
Although I'm very impressed with the (advertised) capabilities of the H2-DM1E and DM Designer SW, I've experienced many difficulties understanding the programming language. The "Help" files were obviously written by the designers/programmers who are too close to the details to be objective and thorough. You need a 2nd party to do a design review and edit on the entire Help text (using a word processor to do the index is unacceptable).
The support (via Email) has been impressive! Thank you. Taking care of the issues I mention above will greatly lighten your load and allow you to do even more impressive things.
I chose Do-more for it's powerful capabilities and the power of the software structures. I'm confident that your product will resolve the challenges my customers present to me, but the "learning curve" is killing me.
Dave Moyer
-
What aspects are you having trouble with? About the only thing I found potentially treacherous was trying to understand under what circumstances logic in Programs and Tasks would recognize a change of state (like a leading edge of an internal relay for example), and that's something you can learn by test and experiment.
You can also post on here with questions, and get help not only from Host people but from other users who are learning along with you.
-
BobO,
Although I'm very impressed with the (advertised) capabilities of the H2-DM1E and DM Designer SW, I've experienced many difficulties understanding the programming language. The "Help" files were obviously written by the designers/programmers who are too close to the details to be objective and thorough. You need a 2nd party to do a design review and edit on the entire Help text (using a word processor to do the index is unacceptable).
The support (via Email) has been impressive! Thank you. Taking care of the issues I mention above will greatly lighten your load and allow you to do even more impressive things.
I chose Do-more for it's powerful capabilities and the power of the software structures. I'm confident that your product will resolve the challenges my customers present to me, but the "learning curve" is killing me.
Dave Moyer
I'm sorry you've found it difficult to learn and found the help system inadequate. Host is a pretty small company with limited resources, and at this time it is simply not possible to contract an outside entity to re-develop the help system.
There are a number of other resources available however: a) AutomationDirect's Do-more manual, b) a number of informative videos provided by AutomationDirect, c) a free subscription to Interconnecting Automation's training videos, and d) the Start Page in Designer. Have you made use of these other resources, and if so, can you give me some more specific information about what areas we should emphasize?
-
BobO,
I have been quite impressed with DMD's help file. It has had nearly everything I've needed to know (as long as I stay away from the far corners of the envelope ;D ).
I too would be curious what dmoyer was unable to find there.
-
BobO,
I have been quite impressed with DMD's help file. It has had nearly everything I've needed to know (as long as I stay away from the far corners of the envelope ;D ).
I too would be curious what the dmoyer was unable to find there.
Since when have you stayed away from the corners?!? ;)
It was always my vision that there be two primary sources of documentation: 1) a manual and 2) a help system. The manual was to be more high level, focusing on the how-to...what instructions you used and why, and how to put it all together. The help system was intended to be the details of how each instruction worked and what its parameters did. This philosophy was borne out of the type of documentation you find for compilers. The help documents the key points about the tools and programming APIs, but doesn't teach you how to be a software developer.
Since ADC developed the manual and Host developed the help system, it didn't happen quite like I hoped, and the manual ended up as something different than I had envisioned. Although what ADC created was needed, we still don't have a "Teach Yourself to Program Do-more in 21 Days" and I think we need that. Once you get through that process, most folks seem to really enjoy Do-more...but...we'd be lying to ourselves if we think that process isn't difficult for some people, depending on the type of experience they have. I really wish we had a better way to get the "light to turn on" faster...because once it does turn on, the largest majority love Do-more.
-
Since when have you stayed away from the corners?!? ;)
Ummm... If you could just see what I am working on now... ;D
I do think it would be great for someone to put together an online (or offline) tutorial with keystrokes and screenshots of an entire project that someone could sit down and follow at their desk, and then actually watch it work on the simulator.
It should include:
1) At least one properly implemented PROGRAM without STAGES.
2) At least one properly implemented PROGRAM with STAGES.
3) At least one properly implemented TASK.
4) STRPRINTS with several data types being formatted into visually useful data.
5) STREAMOUTS to DmLogger so the data can be viewed.
6) MATH illustrating Boolean logic (RLL encapsulated in MATH).
7) MATH illustrating standard mathematical equations.
8) A FOR/NEXT loop.
Optional:
1) A properly structured Program that could open, receive, send, and then close a MODBUS device.
2) A properly structured Program that could open, send and/or receive data from a TCP server.
-
Since when have you stayed away from the corners?!? ;)
Ummm... If you could just see what I am working on now... ;D
I can only imagine. Your projects make me feel better about my product, and at the same time, scare the poo outta me. ;D
I do think it would be great for someone to put together an online (or offline) tutorial with keystrokes and screenshots of an entire project that someone could sit down and follow at their desk, and then actually watch it work on the simulator.
It should include:
1) At least one properly implemented PROGRAM without STAGES.
2) At least one properly implemented PROGRAM with STAGES.
3) At least one properly implemented TASK.
4) STRPRINTS with several data types being formatted into visually useful data.
5) STREAMOUTS to DmLogger so the data can be viewed.
6) MATH illustrating Boolean logic (RLL encapsulated in MATH).
7) MATH illustrating standard mathematical equations.
8) A FOR/NEXT loop.
Optional:
1) A properly structured Program that could open, receive, send, and then close a MODBUS device.
2) A properly structured Program that could open, send and/or receive data from a TCP server.
I think that is an excellent idea. I would love them to be videos and readily accessible from the Start Page.
-
Excellent idea. Host them on YouTube or somewhere generic so we can access them from phones, tablets, etc., when we're not running Designer, and just put links in the Start Page.
-
I have used the Do-More cpu on several projects now and love it. I think the "MATH" box is a real time (and code) saver. Used to have to input several rungs of code to do simple math functions. All of the improvements over DirectSoft are awesome. My last project had 100 complicated recipes, data logging, Modbus, ethernet, and PID loops for motor control. The project took about half the programming time. Keep up the great work! For future improvements, add a "SMOOTH" box to do moving average smoothing on lumpy data.
-
I have used the Do-More cpu on several projects now and love it. I think the "MATH" box is a real time (and code) saver. Used to have to input several rungs of code to do simple math functions. All of the improvements over DirectSoft are awesome. My last project had 100 complicated recipes, data logging, Modbus, ethernet, and PID loops for motor control. The project took about half the programming time. Keep up the great work!
Thanks for the kind words. One of the most common comments we get is how much smaller code gets. I love hearing that because I know from my 25 years experience that 'smaller' isn't just more efficient, it's less buggy and much easier to maintain in the future.
For future improvements, add a "SMOOTH" box to do moving average smoothing on lumpy data.
Already there...it's called FILTER.
-
I just completed a retro-fit of a 35 year old purged gas electric heat treating furnace. We did one of there about 8 years ago with a DL205/260, this one I used a Do More processor. I started from scratch just to see how the engineering/programming time would compare. I did not write the first one and this one has more recipes/curves than the first one. It took about 25% of the time to complete!! Also a BIG kudos on the PID look tuning. I gave up on the DL260 and just tuned them by hand, I gave the Do More a shot and it nailed it first time (as good or better than I could have done in less time)
Keep up the good work!!
Thanks,
JW
-
OBSERVATIONS - Do-more Designer 1.3.1
We recently purchased a Do-more H2-DM1E to get acquainted with. I admit to waiting until it had a little maturity as I have tired of that bleeding edge stuff. Hopefully we will be getting a PO for a job with a very good fit shortly. We usually get very little time to play with new products before they have to be installed and running and the last "good fit" had too short a window to want to attempt it.
Firstly, note that I am loving this new processor and it's capabilities and I am fully aware the programming software is made available for free. Therefore, the following are just observations and my experiences (and implied hopes.)
Zoom Level with 1.3.1 in XP 32bit most always goes to 35% regardless of what is selected. Zoom In and Zoom Out work OK as does the mouse wheel. I have had it work OK intermittently.
System Variables should be user describable and should be shown in Documentation Editor. This one is important to me as it can be more verbose.
I'm not real wild about the auto "clean" of unreferenced elements in Documentation Editor. I added them so why are they being deleted?
Please, please do something to make the ladder elements/nicknames actually large enough to read when status is on. Zoom level must be ridiculous to actually see the element.
Yes I have played with the fonts in the .ini file but have not seen a helpful change. Also note that many of us using the software are out on a plant floor with a laptop, usually of ridiculously poor resolution due to the move to consumer video format, and no second monitor. I do field service, short notice at times so this is the norm.
In ladder status, why is the number of decimal places less than in Data View, and at least for a timer accumulator, gaining an extra digit when it is zero?
If a timer, counter, etc. has a description or extra info, it would be really, really nice to have this automatically be used as the default pass-thru for the .Done bits, etc. But they should still be over-writable if desired.
Can't drag icons off the tool bar if they are greyed out when trying to customize.
I would like to be able to select how timer time presets and accumulators are displayed, sometimes the expanded format is clunky and sometimes it is nice, but it depends on the application. A quick way to toggle would be even better. OK, I can set it as a constant mS in variable location but it still shows expanded in ladder :(
I would prefer the Cross Reference (and pop up cross reference) to show rungs and not addresses which are meaningless to me.
I NEED User Structs. I need to mix and match data types in those structs. For instance, I have 20 VFDs that I want to have access to via Modbus. I really don't want them spread all over a data table. On the other hand, I can't even create a data table named VFD01 and another named VFD02, etc., as that is not allowed. Even if it were, I am stuck with casting the bits, etc. Arrays might work, but... that's a whole 'nother layer of obsfucation.
When starting a new project, any caps in the filename are replaced with lower case. What a pain. (DirectSoft does this also.) It does not do this with Save As.
There is no way to create new nicknames in the LERP instruction Input or Output Points. This may be true elsewhere too, I haven't stopped to record everything I found "glitchy".
It's very vague where nicknames are going to be shown versus elements. This pretty much blows up the whole "tagname" argument. See the LERP instruction for an example. Well I maybe found this in the options but...
If you just move to the output column of a rung and begin typing a new nickname, it gets entered all in upper case as if you are typing an instruction, which is baaaad.
The variable width toolbar icons, due to spelling out things like "Previous" etc., eat up a lot of real estate. Frankly the old small (only selectable in the .INI file) icons in DS4 were far, far better. I hated having to remember to edit the .INI, but I hate losing the DS4 small icons even more. The DS4 icons are much clearer, cleaner and less blobby - intuitive even :) Yes, the large icons are pretty but they do not scale and they steal valuable screen space. Without the text on, I can't make heads or tails what the small icons are even supposed to be.
A TMR in $Main does not reset to zero when transitioned from RUN to PROG and back to RUN! Huh?
Nicknamed timers do not show up in the auto complete pick box for contacts! They have to be fully typed or use the element.
RANDINT and RANDREAL are just begging for parameters - e.g. RANDREAL(2.50,7.50) to scale the value to those two endpoints (Also RANDREAL(R0,R1) ) inclusive.
LERP works, but is not elegant in this situation. (LERP is Fabulous in itself however!)
In the Ladder display, a SET coil under an MRX (or other) box is not right justified.
Right Click menu "Delete" will not delete an unassigned nickname in Documentation Editor, <Delete> key will.
MAPIO dialog box highlighting just seems backwards. The dark blue should be the selected field. I am having alot of trouble making my head work with this. It would also be much preferred if I could simply cursor down the inputs and outputs rather than have to hit <Enter> and it goes right or CR/LF. If I have a pattern of in and out addresses it is far, far easier to do the patterns downwards than shift gears back and forth. Double <Enter> works I guess, but then there is the wrong highlighting screwing me up. Same thing in Documentation Editor. Excel lets you pick default behavior, hint, hint. :)
Firmware updates are easy enough to download, but it is unclear when they are completed. It seems you have to do it twice at times to get them all, but the Go! button never grays out.
Once you have downloaded the firmware updates, how do you install them? The help file index for "Update Firmware" opens Password Configuration instead. I finally found where to Update the Processor firmware, Live Update DID NOT take me there after the download and I only got hints from the help file where to find it.
The help files need a lot of "help". Check out the UDC instruction:
".Done - (Read-only) if the instruction is configured to use an Up Preset, is ON any time the value in the Counter structure's accumulator (.Acc) is less than or equal to the Up Preset value"
Why are all the items in the Project Browser that you can't do anything with, e.g. Memory? Right click context for them is just generic with too many items anyway. A double click just takes you to the top of the tree. A double click should maybe take me to the configuration for that memory block. (You guys seem Siemensie, I have to keep looking these terms up - i.e. rather than Data Table ;) )
Can we disable the Element Browser? I hate that thing. It is always popping up when I am trying to mouse click focus on a field (Yeah, yeah, Microsoft mystery click count.) I hate it, I hate it and I find it worse than useless. (That's kind of strong and others probably love it, but it has never clicked with me.)
If you inadvertently start a rung edit (way too easy when just trying to move around) and you <Esc> to get out, you have to select "No" to cancel the changes and this drops you out of edit mode - what a pain. (Yes it has done that forever in DS also and it's a pain there too.) And it ALWAYS says rungs have been changed even if nothing has been.
Trying to right click add a rung data view does not add anything except contacts and COILS, no MOVE contents, MATH contents, etc. Further, every addition is a new data view window. Can we get everything and just add it to an open data view? It's cool, but kind of useless as is. I am far more interested in the numbers, not the bits and I want them all at once and together. Closing all those extra data views is tedious too because I 'x' it and then have to move the mouse over to tell it not to save it.
If I enter a contact DLV10100:1 on a new rung, then select it, then <Ctrl><D> it doesn't take me there (it doesn't even exist?). DLV10100 already exists and is used as is DLV10100:0 (with a nickname for it even). If I complete the rung and Accept it, then <Ctrl><D> takes me there. Again DLV10100:1 ought to pass-thru the description (if not the nickname) for DLV10100.
Is there anyway to easily (hot key or icon) toggle the nickname view on or off? Many of the instruction boxes only display the element or the nickname and nickname wins if it is on. This is fine, but I need to be able to quickly toggle them off and on to see the element (address). BTW, where is the list of hot keys? I looked all through the help.
I haven't checked, but I am guessing documentation changes are saved as they are entered :( Is there anyway to change this behavior? It's all very well to be able to undo ladder changes, but if the annotation is not undone also... Or if I start making changes, I can't simply abort because annotation _has_ been changed. I always found this to be an issue with DirectSoft because it WAS going to change file timestamps simply because you opened it to view. Well, I just checked part of this. Changing a rung comment is now a program change that wants to be saved/written before exiting. Selecting No then closing DMD does delete the comment as it is not there when reopened. And now I have found what the S P D are at the bottom of the screen, so I think I am cool with this.
Subroutines! We need subroutines! I need to know the logic is going to run and it's going to run NOW when it is called. Everything else is just not the same. I am not going to claim I have tons of programs that need to be converted, but I frequently use subs to keep them out of the way until needed, but when they are called, it is because I need an answer, I need it now, and I don't need a bunch of code repeated multiple times, because I need the solution it provides right NOW! Plus editing multiple instances just stinks. Passing parameters is wonderful, but it is the icing on the cake.
Stages may be great, but they really don't fit my needs so well. For me, everything is happening all the time and together, if it's not, something bad is happening. So I have a lot of math going on, fast response PIDs, operator interface, some turret indexing that _could_ be done in stage, maybe (but probably not), occasionally some recipes. Subroutines, or Functions or Add on Instructions are great for handling VF or DC drives, load cells, dancers, any place there is more than one instance of a real world device. Function Block Diagrams are handy too.
I have not been able to setup the PLC Link via ethernet. I was able to set up the IP address with a serial cable and manually setup a Link to connect via ethernet and that is it. The Do-more simply does not show up, period. This is with two different computers. Both will connect with the manually configured link using the assigned IP address. And NetEdit3 shows nothing but an ECOM in a D0-06.
Just so you know I DO LIKE THE Do-more:
ModbusRTU comms to 20 VFDs is very nice even at just 38,400 baud (I was subbing the Do-more in for a D2-260 (only 38,400 max) as a test and did not have time to up everything to 115,200 to test it. Reading 9 registers from 20 drives was completing in less than a second, maybe closer to 1/2 a second or better (my sense of time is iffy.) I should have set up a timer, but I was just eyeballing a counter counting successes to one of the 20 drives. I wish I had had the time to test further, but they needed to ship the panel. The help on the MRX instruction does not really mention that no manual interlocking is needed (read that on the forum), just pop in a SETUPSER and 20 MRXs and you are done. I did have some interlocks in case a VFD was not enabled (or if it did not answer I skipped it for awhile.) I set the timeout for the built-in serial port to 200mS and I could see the counter hesitate that long and then resume "clicking" away.
I have only gotten to play with ModbusTCP to one device so far but it is SWEET. I recently did a D2-260, ECOM100 and 7 ModbusTCP devices, I had to set my ladder watchdog to 5 seconds to prevent 'false' timeouts. It was anything but sweet. Yes I did ask about this on the HostEng forum and it is as nice as I was told.
The DELTA instruction is very nice, no need to remember the previous value now for some situations.
Wow, I just "discovered" the Launchpad flyout. I _like_ the Windows shortcuts provided. And YES, I just found how to add/edit them in the DmDesigner1_3.INI file. Nice.
There are many more nice things too, but finding problems is what I do for a living, so they bubble to the top first. ;)
Thanks, it's a great product and I hope it gets even better. Oh yea, and gets migrated to the D0-06 size (price?) platform too.
-
OBSERVATIONS - Do-more Designer 1.3.1
Thanks for the great feedback Mike! We will digest them and get back to you (we are currently working on a number of these already).
-
Zoom Level with 1.3.1 in XP 32bit most always goes to 35% regardless of what is selected. Zoom In and Zoom Out work OK as does the mouse wheel. I have had it work OK intermittently
Make sure the default zoom level is set to 100% (or whatever you want) in your Ladder Options page. Make sure you check New Views in the Apply Options to checkbox list at the top of the Ladder Options page. See the attached screen shot DefaultZoom.png. This does NOT change the zoom level of the current view, just the default zoom level when a Ladder View is first opened (you already know about the Ctrl+Scroll Mousewheel, along with the Zoom level on the toolbar).
Can't drag icons off the tool bar if they are greyed out when trying to customize.
Select View->Toolbars->Customize... to bring up the Customize dialog. When that dialog is up, all the buttons of the current toolbar set should be "enabled" and you should be able to remove (add, rename, etc.) buttons. See the attached screen shot CustomizeToolbar.png.
It's very vague where nicknames are going to be shown versus elements. This pretty much blows up the whole "tagname" argument. See the LERP instruction for an example. Well I maybe found this in the options but...
When enabled in the Ladder Options settings, Nicknames will be displayed in addition to the Element for the FIRST parameter. For instructions with more than 1 parameter, the Nickname will be preferred over the Element text in the Ladder Display (if one exists). In 1.3 we added the option for the Ladder Instruction Editor to prefer the Nickname over the Element Text in the edit field when entering the editor. LERP editor/display may have issues - we will look at it.
The variable width toolbar icons, due to spelling out things like "Previous" etc., eat up a lot of real estate. Frankly the old small (only selectable in the .INI file) icons in DS4 were far, far better. I hated having to remember to edit the .INI, but I hate losing the DS4 small icons even more. The DS4 icons are much clearer, cleaner and less blobby - intuitive even. Yes, the large icons are pretty but they do not scale and they steal valuable screen space. Without the text on, I can't make heads or tails what the small icons are even supposed to be.
Agreed - screen real-estate tradeoffs are always a big concern. You can change the text for any toolbar button by bringing up the View->Toolbars->Customize... toolbar dialog, then right clicking on the actual button on the toolbar, then editing the text (abbreviate as needed or create your own terminology or ?). You can toggle the size of the buttons via the Customize toolbar dialog, select the Options tab, then UNcheck the Large Icons checkbox below the Other group.
Is there anyway to easily (hot key or icon) toggle the nickname view on or off? Many of the instruction boxes only display the element or the nickname and nickname wins if it is on. This is fine, but I need to be able to quickly toggle them off and on to see the element (address).
Use the XRef tooltip. Just float your cursor over the nickname and the tooltip will show you the element name (and Nickname, along with the XRef/Usage info). The element text is not even a mouse click away ;D.
-
The DS4 icons are much clearer, cleaner and less blobby - intuitive even :)
I HATED the DS5 icons. IMO, they bordered on a crime against nature, not only because they were so ugly, but more importantly because they were so muddy and hard to decipher. I called Host specifically to complain how much of a downgrade they were vs the DS4 icons.
As far as I'm concerned, the DM icons are a **HUGE** improvement over both DS4 and DS5 (especially DS5 obviously), both esthetically and for readability.
NOTE: Edited to refer to the DS versions that I was actually talking about.
-
FYI, even the toolbar button graphics are editable from the Customize toolbar dialog. Just right click on the specific button when that dialog is up, and select Edit Button Image menu. Same is true with DirectSOFT Rel 5.
-
Sorry, Mike, I remembered the incident but I was one rev off. I liked the DS4 ones too (though not as well as the DM ones). It was the DS5 ones that I hated and also couldn't read, and that I complained so vociferously about.
Good to know, franji1, I had no idea you could edit icon graphics. Very cool! :)
-
Zoom Level with 1.3.1 in XP 32bit most always goes to 35% regardless of what is selected. Zoom In and Zoom Out work OK as does the mouse wheel. I have had it work OK intermittently
Make sure the default zoom level is set to 100% (or whatever you want) in your Ladder Options page. Make sure you check New Views in the Apply Options to checkbox list at the top of the Ladder Options page. See the attached screen shot DefaultZoom.png. This does NOT change the zoom level of the current view, just the default zoom level when a Ladder View is first opened (you already know about the Ctrl+Scroll Mousewheel, along with the Zoom level on the toolbar).
Can't drag icons off the tool bar if they are greyed out when trying to customize.
Select View->Toolbars->Customize... to bring up the Customize dialog. When that dialog is up, all the buttons of the current toolbar set should be "enabled" and you should be able to remove (add, rename, etc.) buttons. See the attached screen shot CustomizeToolbar.png.
It's very vague where nicknames are going to be shown versus elements. This pretty much blows up the whole "tagname" argument. See the LERP instruction for an example. Well I maybe found this in the options but...
When enabled in the Ladder Options settings, Nicknames will be displayed in addition to the Element for the FIRST parameter. For instructions with more than 1 parameter, the Nickname will be preferred over the Element text in the Ladder Display (if one exists). In 1.3 we added the option for the Ladder Instruction Editor to prefer the Nickname over the Element Text in the edit field when entering the editor. LERP editor/display may have issues - we will look at it.
The variable width toolbar icons, due to spelling out things like "Previous" etc., eat up a lot of real estate. Frankly the old small (only selectable in the .INI file) icons in DS4 were far, far better. I hated having to remember to edit the .INI, but I hate losing the DS4 small icons even more. The DS4 icons are much clearer, cleaner and less blobby - intuitive even. Yes, the large icons are pretty but they do not scale and they steal valuable screen space. Without the text on, I can't make heads or tails what the small icons are even supposed to be.
Agreed - screen real-estate tradeoffs are always a big concern. You can change the text for any toolbar button by bringing up the View->Toolbars->Customize... toolbar dialog, then right clicking on the actual button on the toolbar, then editing the text (abbreviate as needed or create your own terminology or ?). You can toggle the size of the buttons via the Customize toolbar dialog, select the Options tab, then UNcheck the Large Icons checkbox below the Other group.
Is there anyway to easily (hot key or icon) toggle the nickname view on or off? Many of the instruction boxes only display the element or the nickname and nickname wins if it is on. This is fine, but I need to be able to quickly toggle them off and on to see the element (address).
Use the XRef tooltip. Just float your cursor over the nickname and the tooltip will show you the element name (and Nickname, along with the XRef/Usage info). The element text is not even a mouse click away ;D.
I'm sorry, but multi-part quoting looks a bit tedious from this end.
The zoom issue is only when using the zoom level icon, once clicked, regardless of which zoom level is selected, it goes to 35%.
The grayed out icons thing did happen, but I can't reproduce it now. Strange.
The icon appearance editing is cool. Is there an easy way to import the DS4 icons in wholesale or even one by one? How about a DS4 icon mode 'old-farts' tick-box? :) It would make us happy and less grumpy. :-*
The XRef tooltip is good, but I would still be tickled to be able to toggle ALL displayed nicknames off/on with a keystroke or icon because sometimes I am visually "copying/translating" from one program to another and tooltip is too slow for that.
Again, the product is great, but I've learned to get my wishes in while the development is still flexible. Hopefully I didn't wait too long this time.
-
Well, well. Right clicking on a button on the toolbar after you have the Customize window open has LOTS of options, including my favorite icons of all "Text Only"! Unless I am missing something, I had to do them all individually, but I am AOK with that for now. But while I am OK, I would still vote for a universal "Text Only" option in the Customize menu. Going all text also shrinks the toolbar vertically!
BTW, clicking Help in the Customize window gives a "Failed to launch Help!" message.
I am seriously pleased with text only. I know when I don't care for something visually, but I have absolutely no ability to design anything graphical, whatsoever, ever, if you catch my drift.
-
Sorry, Mike, I remembered the incident but I was one rev off. I liked the DS4 ones too (though not as well as the DM ones). It was the DS5 ones that I hated and also couldn't read, and that I complained so vociferously about.
Good to know, franji1, I had no idea you could edit icon graphics. Very cool! :)
I disliked the DS5 icons so much I stayed with DS4. I finally figured out what was hosing my comments though. Opening a DS5 file containing I-Boxes with DS4 is a seriously bad mistake. Since DS immediately writes documentation changes to file, and the rungs are hosed due to unknown instructions, boom, busted comments. I have learned to open temporary copies.
Of course, now this very minute I find out you can edit DS5 icons the same way. AARGHH, hooray!!, AARGHHH, hooray!!
I've got to go change my filename associations from DS4 to DS5 and be happy. I like DS5's docking stuff, I just hated the icons.
Thanks franji1 and Controls Guy!
-
I turn off all the toolbars, and have learned to use keyboard shortcuts. I'm a slow learner, but once I got the common ones memorized, it is a lot faster, and I have lots more screen real estate.
-
Just playing around a little. I can get a nice DS4 icon in DMD, but I don't see an option for editing the grayed out version.
-
One more question on toolbar icon modifications:
Do they all go away on loading the next version, i.e. 1.4.0 or 1.3.2 even? That would hurt, if I spend much time on this.
OK, two questions:
Is there a way to share these mods between computers?
-
I believe all you have to do is copy and paste the .ini file.
-
One more question on toolbar icon modifications:
Do they all go away on loading the next version, i.e. 1.4.0 or 1.3.2 even? That would hurt, if I spend much time on this.
OK, two questions:
Is there a way to share these mods between computers?
Not sure if they will go away and reset back to their defaults. Also, there is no way to import/export the graphics.
As you found out on your own, I was able to copy a DirectSOFT Rel 5 button into Designer (as you did with Rel 4). You might be losing the "transparent" pixel. When grayed, a button's non-transparent pixels are drawn dark gray, all transparent pixels remain transparent. So it appears that your transparent pixels became non-transparent, and hence when "grayed", looks like a square.
-
As you found out on your own, I was able to copy a DirectSOFT Rel 5 button into Designer (as you did with Rel 4). You might be losing the "transparent" pixel. When grayed, a button's non-transparent pixels are drawn dark gray, all transparent pixels remain transparent. So it appears that your transparent pixels became non-transparent, and hence when "grayed", looks like a square.
I played with it some more and was able to get the grayed out "look" pretty decent. It is a lot of work though - especially since I am not sure what it is that I am doing that is working. :-\
Text is looking better all the time, but the old DS4 small icons sure are nicely compact.
It sure looks like DS4 used multiple sets of icons for the various states as it has colors even for the disabled icons.
Thanks!
-
I'm sorry, but multi-part quoting looks a bit tedious from this end.
It's actually not too bad. Just enclose each quoted snippet with '[ quote ]' and '[ /quote ]' (remove the spaces, obviously, and it doesn't get you the attribution, but big woop).
I also use a Firefox plug-in called BBCode Xtra or Html Xtra or something like that on some other boards that will allow you to swipe across blocks of text and apply html codes for blockquote, italics, bold, etc., and it has commands for BBCode in addition to the html ones.
-
Having some weird issue with updates. Check for updates, says there are two help files where I'm at 1.3.1.1 and 1.3.1.2 is available. Download, click "Yes" to update, it tells me to exit DMD and click "Retry", I do so, and it just keeps reverting to that same dialog telling me to quit DMD and click Retry.
-
Having some weird issue with updates. Check for updates, says there are two help files where I'm at 1.3.1.1 and 1.3.1.2 is available. Download, click "Yes" to update, it tells me to exit DMD and click "Retry", I do so, and it just keeps reverting to that same dialog telling me to quit DMD and click Retry.
Try rebooting and try again.
-
Having some weird issue with updates. Check for updates, says there are two help files where I'm at 1.3.1.1 and 1.3.1.2 is available. Download, click "Yes" to update, it tells me to exit DMD and click "Retry", I do so, and it just keeps reverting to that same dialog telling me to quit DMD and click Retry.
I tried to duplicate it per your description, but it's working properly for me. When I got to the point where I closed DmD and clicked "Retry", the installation completed successfully. The only thing I know of that would cause that behavior is another open DmD window. Even having a DmD 1.2 window open while trying to update 1.3 would cause that dialog to show up (all it's looking for is a running DmDesigner.exe process).
-
Don't think there were any other instances running, but trying again after a reboot seems to have done the trick. Thanks!
-
Don't think there were any other instances running, but trying again after a reboot seems to have done the trick. Thanks!
As ever, the sage words of Roy from the IT Crowd save the day.
(https://forum.hosteng.com/proxy.php?request=http%3A%2F%2F24.media.tumblr.com%2Ftumblr_m3yz13kTE41rsxd68o1_500.gif&hash=09f1e87c2e04425783e564ec89ed7cfeba7ff5eb)
Reminds me of a recent trip overseas that I took. We were waiting at the gate to board the 747, and the announcer came over the PA to announce that, no joke, they had to "restart the plane" because there was a glitch in the electrical system. Must have been running Windows.
-
LOL, no doubt!
-
When I download a file that creates messages (not even "Warnings"), I'm notified and given the chance to proceed with the download or cancel. There is also a check box which is supposed to cause it to download all files with no errors, but even if I check the box, the next time I download, the dialog still appears and the box is unchecked. Bug? Or am I doing something wrong?
-
Sounds like a bug.
-
It's not a bug. That flag is maintained per session, by design. If during this session, if you say "don't notify me again", we don't bother you again for that specific Designer session.
The question was how long do we maintain that state. What if you create 100 new warnings? Don't bother letting you know in the middle of a runtime edit? Which warnings/messages from 5 months ago do you need to not care about and which new ones do you need to know? If we made that checkbox lifetime last a lifetime, there might be some critical warnings that you would miss in the middle of that 2AM runtime edit.
Hence, we decided that the lifetime of that checkbox was ONLY during that session. Not a global option. Not a part of the project.
BTW, we have implemented a much better mechanism for handling the root issue - that there are some messages (and even warnings) you KNOW that you do not need to care about. In the next release, you will be able to IGNORE any specific message or warning at one of 4 different scopes:
- Rung Level
- Code-Block Level
- Project Level
- Global Level (across all projects on that PC)
Once you can do THAT, you can intelligently ignore specific warnings/messages, and if the Program Check at Download dialog DOES come up, you may want to re-visit that code and/or tweak the "ignored" state of those specific rule "violations". (You can still "ignore" it during that session).
-
I always have that message for the first download to each processor after starting DMD. I figured it was meant to be that way...
-
Has anyone mentioned the tendency of DmD and DSx to change the case of project names when they are created? It's really annoying. DmD just changed my nice project name to all lower case. It seems like DSx always wanted to make it upper case.
>:(
-
Has anyone mentioned the tendency of DmD and DSx to change the case of project names when they are created? It's really annoying. DmD just changed my nice project name to all lower case. It seems like DSx always wanted to make it upper case.
>:(
Hateful Host Engineering people... ::)
Can we fix that, Mark?
-
Has anyone mentioned the tendency of DmD and DSx to change the case of project names when they are created? It's really annoying. DmD just changed my nice project name to all lower case. It seems like DSx always wanted to make it upper case.
>:(
Hateful Host Engineering people... ::)
Can we fix that, Mark?
I wrote up a FogBugz case for it. Hopefully it will be easy.
-
Has anyone mentioned the tendency of DmD and DSx to change the case of project names when they are created? It's really annoying. DmD just changed my nice project name to all lower case. It seems like DSx always wanted to make it upper case.
>:(
Hateful Host Engineering people... ::)
Can we fix that, Mark?
And there's the problem with smileys. :-[ There wasn't one for frustrated so I picked the closest "look alike" I could find.
BTW, the Save As has always worked fine, but you have to change the name for that to work. There is also some point in there that it seems to corrupt the file if I try to Save As before it has saved the first time. I tried it twice at least and couldn't open the file afterwards. It is OK after it has asked for the project description and all (sorry, I don't have it open to get the correct name.)
I was starting my third Do-more project BTW.
-
There is also some point in there that it seems to corrupt the file if I try to Save As before it has saved the first time.
If you can give us steps on how to reproduce it, that would be great! I tried it with a simple STR X0/OUT Y0 project saved via "Save As" dialog to "SaveAs1", closed the project, then open SaveAs1.dmd, and it worked for me. That doesn't mean there isn't an issue, it just means that there are other steps involved that maybe you can provide ;D.
-
There is also some point in there that it seems to corrupt the file if I try to Save As before it has saved the first time.
If you can give us steps on how to reproduce it, that would be great! I tried it with a simple STR X0/OUT Y0 project saved via "Save As" dialog to "SaveAs1", closed the project, then open SaveAs1.dmd, and it worked for me. That doesn't mean there isn't an issue, it just means that there are other steps involved that maybe you can provide ;D.
I see why you don't see it. I almost never save a new project to the default folder. So on New File - Offline - pick a processor - click Browse - change to a different folder - type filename with mixed case - Save - All lower case now. If I let it create it in the default folder it doesn't do the case change. The path is all lower case also after the browse selection. This is all before clicking OK.
-
Oh yeah, default folders for apps. Lamest idea EVER. Why would I want to store my docs in a hierarchy related to what project they're part of when I can organize them based on the fact that I created them in Word or whatever. [eyeroll]
-
All lower case now.
OK - you're talking about the FILENAME becoming corrupted (i.e. becoming all lower case). Yes! I see that when I do SaveAs to a different folder. I thought that you were talking about the project FILE becoming corrupted. Sorry about that. We will address it.
-
Oh yeah, default folders for apps. Lamest idea EVER. Why would I want to store my docs in a hierarchy related to what project they're part of when I can organize them based on the fact that I created them in Word or whatever. ::)
[Emoticon edit ;D].
Yeah, that's still the default behavior. However, you can easily override it using the File->Manage Projects->Folder Settings dialog (see attachment). Just change the Projects Folder via the Set Projects Folder... button.
-
Oh I do, believe me. I set the default to the main projects directory. I still have to navigate from the default, but at least that gets me 50% or more of the way there. My comment had more to do with the laughable degree of app-centricity of the developers of Word or whatever app, thinking that there's even the remotest chance you'd choose to organize your files that way and making it the default. It's not an automation software thing per se; everybody does it and it's just dumb IMO.
-
All lower case now.
OK - you're talking about the FILENAME becoming corrupted (i.e. becoming all lower case). Yes! I see that when I do SaveAs to a different folder. I thought that you were talking about the project FILE becoming corrupted. Sorry about that. We will address it.
Oh I can do that too! After you allow it to create the project with all lower case, try to Save As. It won't allow you to just fix the case and save it. So close the project. In Windows, I go and fix the case of the 3 files it has created. Now you cannot open the Fixed Filename.dmd project - "Error reading project file!"
-
After you allow it to create the project with all lower case, try to Save As. It won't allow you to just fix the case and save it.
Saw that - Windows file name can contain upper and lower, but the file system is case Insensitive, so you cannot have "abc.dmd" Save-As to "ABC.dmd", because it's the same file (you can only "save" it, not "save-as" to a "different" file that is the "same" file).
So close the project. In Windows, I go and fix the case of the 3 files it has created. Now you cannot open the Fixed Filename.dmd project - "Error reading project file!"
I changed the 3 all lower case files
"bsaveas.dmd", "bsaveas.wsp", "bsaveas.xml" to
"BSaveAs.dmd", "BSaveAs.wsp", "BSaveAs.xml" using Explorer
and it opened just fine in Designer. I am using DmD 1.3. Is that they way you see the error, or do I need to do something different?
-
The thing I am maybe doing different is not creating any code at all before closing the project (after it won't let me Save As the same name but different case.) In other words, it is pretty much a null project. It is most likely a case no one will usually see, but I ran into simply because I wanted to fix the filename.
-
It's not a bug. That flag is maintained per session, by design. If during this session, if you say "don't notify me again", we don't bother you again for that specific Designer session.
Sounds reasonable, but if that's the decision, you need to change the "always" word. I associate "always" with the "forever" thingy. :D
The question was how long do we maintain that state. What if you create 100 new warnings? Don't bother letting you know in the middle of a runtime edit? Which warnings/messages from 5 months ago do you need to not care about and which new ones do you need to know? If we made that checkbox lifetime last a lifetime, there might be some critical warnings that you would miss in the middle of that 2AM runtime edit.
Except how could that actually happen when the Output window opens anyway even with the box checked and needs closing with each and every download?
-
Sounds reasonable, but if that's the decision, you need to change the "always" word. I associate "always" with the "forever" thingy. :D
Fixed. Changed it to read
"Do not ask again during this session - okay to download if no ERRORs"
Except how could that actually happen when the Output window opens anyway even with the box checked and needs closing with each and every download?
The Output Window is not modal, it's just a docked view. The download/runtime edit would will have already occurred if we did not have that prompt/message box. Better safe than sorry.
-
Fixed. Changed it to read "Do not ask again during this session - okay to download if no ERRORs"
Good deal. That will be much less confusing to your more literal customers like me.
The Output Window is not modal, it's just a docked view. The download/runtime edit would will have already occurred if we did not have that prompt/message box. Better safe than sorry.
It might not be modal but it sure is persistent. I even tried shrinking it down to 1/4" or so since as you note, it's a docked window, but I believe it kept resizing itself and stealing my screen space with every download, so I have to close it each and every time. I think you may want to have a talk with it. I don't think it's taking my check-box very seriously.
-
The output window can be a pain.
What I have learned to do, is to always leave the window docked in auto hide. It hardly ever bothers me anymore.
If you close it (like I used to do) then it takes over every time it thinks there's a problem.
-
Oh yeah, autohide. Cool idea, didn't think of that -- thanks plcnut!
-
I've had the privilege to see some of plcnut's code, and trust me when I say that he pushes hard enough that warnings and info in the output window would be fundamental to his programming experience. ;)
-
I can only aspire to one day live as close to the bleeding edge as 'Nut!
-
I can only aspire to one day live as close to the bleeding edge as 'Nut!
Oh goody...even more nightmares for the development team...
-
It's the "Cause of ma laff"! [/John Edwards voice]
-
When connected to the processor via the USB port, powering down the PLC seems to be locking up DmD 1.3.1. I have had this happen every time. I am thinking Ethernet always recovers when power is reapplied. This is kind of a bummer and I know I should "disconnect" first, but how often is that going to happen? ::)
I probably should have tried to see exactly what is happening, but it's always an "under the gun" time-frame when I run into this. I figured at first it may have just been my laptop, but I have seen it on a desktop and a customer had the same issue.
Any solution besides "disconnecting" first?
-
I have not seen that...cause we certainly wouldn't have shipped it if we had. We routinely power up/down, yank cables, hot swap crap we shouldn't, etc, with no issues. Gut tells me it is a Windows driver issue. Are you using a docking station? A 100 year-old PC? Anything else that might be relevant?
-
Gut tells me it is a Windows driver issue. Are you using a docking station? A 100 year-old PC? Anything else that might be relevant?
No docking station. The PC is certainly not triple digit old, but maybe two. But hey! It runs Rockwell's Allen-Bradley RSLogix so it can't be all that bad.
I run mostly XP. I won't be able to test any further for a few days, but I will try it on a few different (newer and Win7 even) laptops and desktops and see what is reproducible and get back with you. If it should work without this issue I would sure like to help get it cleared up.
-
Just getting started, there's a learning curve (been working with Think N Do too long)but that's part of the fun. Am looking to upgrade all my Think N Do CPU's to Do-More (looks like it will be a big step up in scan time with the testing I've done so far). So far, I like it, I like it a lot. Would like to see one for the 450, yeah I know it's not very popular, but expensive to replace the whole rack.
-
Just getting started, there's a learning curve (been working with Think N Do too long)but that's part of the fun. Am looking to upgrade all my Think N Do CPU's to Do-More (looks like it will be a big step up in scan time with the testing I've done so far). So far, I like it, I like it a lot. Would like to see one for the 450, yeah I know it's not very popular, but expensive to replace the whole rack.
I have replaced a couple winPLCs with Do-mores and have a few more to do. Stage program make it very easy to do. Make each chart a program and each loop point use a stage and it works great.
-
Several of my ThinkNDo programs are around 200 charts, is there a limit to the number of programs Do-more can run?
-
Just image register (256K), program memory (64K), and heap item limit (1000). Depends on complexity, but 200 seems in play.
-
Would like to see one for the 450, yeah I know it's not very popular, but expensive to replace the whole rack.
So swap your 405 CPU for an EBC and run the rack as remote to a DM1E with no I/O. (Hosties, this is doable, yes?)
-
Probably depends on what's in the rack. Remember the 405 had a slew of specialty modules, some dependent on system memory registers.
-
So swap your 405 CPU for an EBC and run the rack as remote to a DM1E with no I/O. (Hosties, this is doable, yes?)
As Do-more Ethernet I/O, no. There is no EBC100 on 405. Do-more only natively supports H2-EBC100, T1H-EBC100, and GS-EDRV100's. None of the old EBC (non-100) models are supported natively by Do-more.
You could make existing H4 bases work using the legacy H2-ERM100 module in a 205 Do-more rack, and swapping out the 450 with the H4-EBC, but it won't be native Do-more I/O. It would show up as DLX, DLY, DLC, and/or DLV. You must also use NetEdit to configure all your 405 I/O, none of which would be stored as part of the Do-more project file.
-
As Do-more Ethernet I/O, no. There is no EBC100 on 405. Do-more only natively supports H2-EBC100, T1H-EBC100, and GS-EDRV100's. None of the old EBC (non-100) models are supported natively by Do-more.
Oh OK. So many EBC's are supported natively, I assumed they all would be. The serial port on the 405 will also do Modbus RTU, so that would be another option. I've used 405's (and 205's) as remote Modbus I/O that way before.
-
So many EBC's are supported natively, I assumed they all would be.
Do-more uses a special mode with some advanced features. It simply wasn't practical to add support in the original EBC.
-
Oh, so you're saying you modified the EBC's now compatible with Do-More to make them so?
Oh, and the H4-ECOM100's also support Modbus/TCP.
-
Oh, so you're saying you modified the EBC's now compatible with Do-More to make them so?
Yes.
-
I'm working on a project that includes a GOTO instruction. Everything is in $Main for this one. But on Save or Check I get 45 messages like:
[Message] $Main@1325 M331 Asynchronous instruction TMR used in code-block with 1 yielding instruction (GOTO at @873)
But I only have a few timers between the GOTO and LABEL and it is telling me about every timer in the program, even those with no coils or contacts within the range.
I know the ones between the GOTO and LABEL will probably always be a message source, but with 45 of them (and indicating position, not the rung - blech), it is kind of anti-helpful.
So what would be the best way of implementing this conditionally skipped code anyway? This is a retrofit project and we don't want to reinvent the wheel on this one, just translate and go - hence all in $Main.
-
Next version will allow you to control what program check rules are applied globally and I think possibly on an instance basis.
What he's complaining about is that timers may not work correctly if not executed every scan. Any yielding instruction (GOTO is yielding) can result in the program not executing the entire block every scan and can result in timers losing time. In $Main that isn't really a problem due to the default timeslice being 65535 (unyielding), but we can't really know that at program check time, so we complain.
How to handle? Depends on what the conditional code is doing. If it is a part of some computational code and needs to be executed inline, I'd use the GOTO for now, and a FUNCTION or SUBROUTINE when we get them implemented in the future. If the code is just a chunk of code that is enabled or disabled as part of a mode, and was previously implemented in an MLS/MLR section, I'd move it to a TASK block.
-
How hard would it be to make timers initial clock time plus duration based, rather than scan time accumulation based? It seems like there's a couple advantages to that approach and I can't really see a downside (accuracy being one advantage, this issue being another).
-
The RTC isn't nearly as stable as the scan timer for starters. Plus you would be adding a fair amount of complexity to a pretty simple system as it is today. I think there would be quite a bit of complaint over the accuracy of the timing if it were to be done that way and timing accuracy is one thing PLC's are judged on.
-
Hmmm....interesting (and somewhat surprising). I'd have thought that the two were equally accurate, and if told that there was a difference, I'd have assumed the RTC was the more accurate. The other reason I assumed that approach would have improved accuracy was one single rounding error at the end of the time, vs. one per scan so that the error is non-cumulative. Live and learn, I guess! ;)
-
The RTC isn't nearly as stable as the scan timer for starters. Plus you would be adding a fair amount of complexity to a pretty simple system as it is today. I think there would be quite a bit of complaint over the accuracy of the timing if it were to be done that way and timing accuracy is one thing PLC's are judged on.
It wouldn't use the RTC, and actually couldn't, since the RTC is only good to 1 second.
-
Hmmm....interesting (and somewhat surprising). I'd have thought that the two were equally accurate, and if told that there was a difference, I'd have assumed the RTC was the more accurate. The other reason I assumed that approach would have improved accuracy was one single rounding error at the end of the time, vs. one per scan so that the error is non-cumulative. Live and learn, I guess! ;)
The answer to your OP is that it could be done, but would require 50% more image register memory (3 DWORDs instead of 2) since you would still need to store the elapsed time for status displays. The computational hit would be essentially the same.
There is no cumulative error either way, assuming the timer instruction is run exactly once per scan, because there is no rounding in integer math.
At this point, it is mostly moot, since changing the instructions is not an option. It is pretty easy to roll your own though, if this is important to you. In the MATH box, the TICKms() function gives you access to the raw millisecond tick counter that the timer instructions are built on.
-
There is no cumulative error either way, assuming the timer instruction is run exactly once per scan, because there is no rounding in integer math.
That removes the main reason I thought the other approach might be better. Another reason would be timing continuity while the PLC is powered off, but you can still do that manually using the RTC.
At this point, it is mostly moot, since changing the instructions is not an option. It is pretty easy to roll your own though, if this is important to you. In the MATH box, the TICKms() function gives you access to the raw millisecond tick counter that the timer instructions are built on.
I actually don't. My post was in response to what the other guy was asking about, which also kind of tickled some ideas I had had about the timing method.
-
Does DMD or the printer driver handle pagination? Do-More must at least be aware of it, even if the driver's doing it because it can preview. Anyhow, check this image; this follows two NOPs at the end of a program. One of those edge cases that have to be checked for and corrected in real time. Personally I don't mind if you omit the NOPs that print at the end of each code block as well.
-
Does DMD or the printer driver handle pagination? Do-More must at least be aware of it, even if the driver's doing it because it can preview. Anyhow, check this image; this follows two NOPs at the end of a program. One of those edge cases that have to be checked for and corrected in real time. Personally I don't mind if you omit the NOPs that print at the end of each code block as well.
That's kinda icky. Mark?
-
My guys on the Business Development Team at ADC introduced me the to Do-More H2-DM1E and the Designer 1.3.1. Right out of the box, I was impressed with the Hardware and Software.
I do a lot of my work with various arrays. I am used to building these arrays in DirectSoft5 (using the DL260), but the Do-More Designer has made it so much easier. This software is a good tool for those that are accustomed to structured text programming conventions;(I must repeat CONVENTIONS.)
I also use the F2-CP128 for parsing strings from scale indicators. The Do-More H2-DM1E RS232 serial port and Designer string instructions have made this task so simple.
I was excited enough about my first impression that I hopped a flight down to Atlanta earlier this week and attended Doug Bell's training class on the Do-More at ADC.
I could make a list of all of the things that I love about the new hardware/software, but that would be incredibly long. Just know that I REALLY like it.
Thank you for the hard work and development, as well as the sharing of faith.
Here are some questions that I submitted to ADC:
Documentation Editor
C-More Has a Fill Down Option for sequential nicknames/tagnames.
Example: If I create Switch(1), C-More will offer the option of Fill Down which will create Switch(2), Switch(3), etc. MS Excel does something very similar.
Will this ever be an option in the Do-More Designer Documentation Editor?
ST’s vs SP’s
DirectSoft5 has a few SP bits that I used in my programs that I do not see in Do-More Designer. While encoding a word, I would use the SP53 bit to indicate that more than one bit was high in the word. Since the encoding instruction stopped at the LSB, I would reset the bit and execute the encode instruction again. When the word only contains one High bit, the SP53 will not go high. This indicates that I have reached the MSB
that is set high.
Is there an ST bit in Do-More that will give me the same function OR will there be an instruction that allows me to find the MSB that is set high in a word?
Structured Text Programming
Do-More Designer offers:
• Ladder Logic
• Stage Programming
• The new Programs/Tasks that seem to work like Function Block programming
Will Do-More be offering structured text programming in the future? When Siemens offered it in Step 7, it allowed the programmer to pick the right programming language for the task (or the right tool for the job.)
Debugging
Will Do-More Designer be offering BREAKS for debugging code (similar to C# programming in Visual Studio?) The current options are good, but seem to execute the entire scan from Top to Bottom. If I had a 10 rung code, I would like to set a break at rung 5, and move to rung 6 only after I’ve advance the program.
Will C-More be supporting Custom Memory Blocks from Do-More as Nicknames/Tagnames. I understand that this is not your issue. I just thought that you may have some information regarding the subject.
-
Did Frank forward you the answers to your questions? I answered all of these for you last week.
-
Did Frank forward you the answers to your questions? I answered all of these for you last week.
I did get the forward from Frank. When I sent the original email to Frank, I mistakenly thought he was forwarding my email to Host Engineering. I did not understand that I was sending my email to an ADC guy, that would be forwarding to an ADC guy, that would be forwarding to a Host guy. He called you by name, but I thought you were with Host. Once I realized how many channels the forward was going to have to go through, I thought it best to eliminate some of the channels. I hope I did not step on toes. I just thought I would go strait to the source and open up a dialog.
-
ST’s vs SP’s
DirectSoft5 has a few SP bits that I used in my programs that I do not see in Do-More Designer. While encoding a word, I would use the SP53 bit to indicate that more than one bit was high in the word. Since the encoding instruction stopped at the LSB, I would reset the bit and execute the encode instruction again. When the word only contains one High bit, the SP53 will not go high. This indicates that I have reached the MSB
that is set high.
Is there an ST bit in Do-More that will give me the same function OR will there be an instruction that allows me to find the MSB that is set high in a word?
In a MATH box, do
3.322 * log(MyIntRegister)
and assign it to an integer type (N or V). That will give you the MSB position.
-
My guys on the Business Development Team at ADC introduced me the to Do-More H2-DM1E and the Designer 1.3.1. Right out of the box, I was impressed with the Hardware and Software.
I do a lot of my work with various arrays. I am used to building these arrays in DirectSoft5 (using the DL260), but the Do-More Designer has made it so much easier. This software is a good tool for those that are accustomed to structured text programming conventions;(I must repeat CONVENTIONS.)
I also use the F2-CP128 for parsing strings from scale indicators. The Do-More H2-DM1E RS232 serial port and Designer string instructions have made this task so simple.
I was excited enough about my first impression that I hopped a flight down to Atlanta earlier this week and attended Doug Bell's training class on the Do-More at ADC.
I could make a list of all of the things that I love about the new hardware/software, but that would be incredibly long. Just know that I REALLY like it.
Thank you for the hard work and development, as well as the sharing of faith.
Glad you like Do-more. We say it over and over, but we are just getting started. It has been so incredibly freeing to own both ends of the pipe. We've been able to add some really nice features requested by users, and in some cases there really isn't much work to it.
Documentation Editor
C-More Has a Fill Down Option for sequential nicknames/tagnames.
Example: If I create Switch(1), C-More will offer the option of Fill Down which will create Switch(2), Switch(3), etc. MS Excel does something very similar.
Will this ever be an option in the Do-More Designer Documentation Editor?
Sequential fill? Never crossed my mind, which is kinda silly because I use that in Excel and C++ resource editors do the same thing. A fairly easy thing would be to use the Add Record facility and if the Nickname field is filled, automatically propagate it with an incrementing index. Might also be able to do a ranged highlight "Fill" option that would give you a few more options. Neither would be hard.
ST’s vs SP’s
DirectSoft5 has a few SP bits that I used in my programs that I do not see in Do-More Designer. While encoding a word, I would use the SP53 bit to indicate that more than one bit was high in the word. Since the encoding instruction stopped at the LSB, I would reset the bit and execute the encode instruction again. When the word only contains one High bit, the SP53 will not go high. This indicates that I have reached the MSB
that is set high.
Is there an ST bit in Do-More that will give me the same function OR will there be an instruction that allows me to find the MSB that is set high in a word?
So Koyo sets the bad logic flag when there is more than one bit? You could easily use SUMBITS to first determine whether there is more than one. If you were wanting a high bit centric ENCO, we could potentially add a new instruction...maybe ENCOH. Pretty simple.
Structured Text Programming
Do-More Designer offers:
• Ladder Logic
• Stage Programming
• The new Programs/Tasks that seem to work like Function Block programming
Will Do-More be offering structured text programming in the future? When Siemens offered it in Step 7, it allowed the programmer to pick the right programming language for the task (or the right tool for the job.)
Structured Text? The short answer is "yes, eventually". We'd like to do SFC, FBD, and ST. The eventually part is just that we have so many wants it's going to take a bit to get there.
Debugging
Will Do-More Designer be offering BREAKS for debugging code (similar to C# programming in Visual Studio?) The current options are good, but seem to execute the entire scan from Top to Bottom. If I had a 10 rung code, I would like to set a break at rung 5, and move to rung 6 only after I’ve advance the program.
Breaking ladder logic is kind of tough. It's doable, Programs and Tasks essentially do it already, but was more complexity than we wanted to engage initially. We intentionally chose to stick to the stuff that we knew we could nail, but are open to trying more stuff going forward. I have a guiding design philosophy: "I'd rather apologize to 20% of the market for what I don't do, than to 100% for what I did poorly".
Will C-More be supporting Custom Memory Blocks from Do-More as Nicknames/Tagnames. I understand that this is not your issue. I just thought that you may have some information regarding the subject.
Sorry, I don't know anything about C-more's development plans.
-
Did Frank forward you the answers to your questions? I answered all of these for you last week.
I did get the forward from Frank. When I sent the original email to Frank, I mistakenly thought he was forwarding my email to Host Engineering. I did not understand that I was sending my email to an ADC guy, that would be forwarding to an ADC guy, that would be forwarding to a Host guy. He called you by name, but I thought you were with Host. Once I realized how many channels the forward was going to have to go through, I thought it best to eliminate some of the channels. I hope I did not step on toes. I just thought I would go strait to the source and open up a dialog.
You are welcome to post here anytime. Customer feedback is absolutely critical to product improvement. Please do so...often.
-
In a MATH box, do
3.322 * log(MyIntRegister)
and assign it to an integer type (N or V). That will give you the MSB position.
[/quote]
Thank you so much.
-
I just want to thank:
ADC Product Engineer
Controls Guy
BobO
Each of you have been very helpful. I expect to learn a lot from viewing your many posts.
-
We have about 7 Terminator Do Mores in the field. All work well but one (1). The CPU will turn itself "OFF" and than back "ON" maybe twice in 8 hours for no reason. We've check all the wiring and all the wiring is good. We use the Terminator 24 vdc power unit only to supply the CPU. We use a separate P.S. for the rest of the I/O. We've replaced the CPU but have the same results. Two of my thoughts are 1. replace the power supply. 2. This company has two (2) or three (3) rather large transformers with-in 4 feet of our machine could this cause a problem?
Has anybody else had a problem like this?
-
What is the value contained in DST385?
-
Custom Data Types would be really neat for the next generation of the Do-More.
Example:
A motor has several characteristics:
Speed: REAL
Amperage: REAL
Running Status: BIT
So, Motor could be a CLASS, while Speed, Amperage, and Running Status could be a METHOD.
If Motor.Speed > 0 then
SET Motor.RunningStatus;
End If;
Is this a possibility later down the road? If this is already a feature, then I apologize. I just haven't found it yet.
-
Is this a possibility later down the road?
Definitely. We refer to them as User Structures. For the exact reasons you specified (and more). But, they are still on the drawing board. But it is at or near the top!
-
Thanks, Franji1! This is great news.
-
What does it do to make program structures retentive? Remembers status bits like .Running, .Done, and so on and last yield point on a program to run transition?
-
What does it do to make program structures retentive? Remembers status bits like .Running, .Done, and so on and last yield point on a program to run transition?
They are all retained following a power cycle (from RUN mode), but everything is reset when doing a program to run transition. $Main is always reset.
-
Got it, thanks. VERY helpful trending MyProgram.RunCounter today -- so cool! Found out the program was running more often than it was supposed to, and had to revise the RUN rung logic.
-
Got it, thanks. VERY helpful trending MyProgram.RunCounter today -- so cool! Found out the program was running more often than it was supposed to, and had to revise the RUN rung logic.
The effort to develop Trend View was worth it just for the benefit to us while developing the engine. Invaluable tool.
-
It really is. I've used it multiple times on every project I've done since I was aware of it. Troubleshooting logic, looking at events external to the control system, seeing what various programs do to scan time so you can decide how yieldy to make them, etc. You can do doggone near anything with that thing! :)
-
Oh yeah, trend view solved another problem for me today as well.
There are a number of I/O lines where another control system sends me a recipe pointer. I start processing that workpiece and set a flag requesting the next queued job. I was asking, they weren't telling, despite there being physical work there.
Trend view showed my physical entry switch, my subsequent request for next part, and from them.....nothing. Later it was sending recipes spontaneously without being asked. Can't really argue with a trend view in a case like that.
In both cases, I just took a screenshot of Trend View, emailed it to the customer, and let him get it sorted with the makers of the other control system.
-
Feature request:
Could you please add CTRL+A (select all) to the Rung comments editor?
Thanks!
-
Could you please add CTRL+A (select all) to the Rung comments editor?
We will add it.
-
Cool beans! :)
-
Just downloaded version 1.4.1 today. Thanks for all of the hard work, HOST Engineering!
-
Bug or Glitch.
I have encountered a certain bug or a glitch a couple of times now. While in the Clean Documentation Database, an error window will pop-up stating "Encountered an improper argument" and offers an OK selection. This selection will not remove the pop-up and will freeze the window.
I have attached pics. These pics are from two separate encounters.
Let me know you're thoughts. Thanks.
-
One of the pics failed to make it. I am resubmitting.
-
One of the pics failed to make it. I am resubmitting.
I sent you a private message.
-
One of the pics failed to make it. I am resubmitting.
I sent you a private message.
Thanks. I will see if I can duplicate it and get back to you.
-
Instruction request!
After hard-coding all the E-stop stuff in to kill all except two programs. I came up with the idea of a Kill-All-Programs with Exception-list and should only be able to use the instruction in $Main.
-
Instruction request!
After hard-coding all the E-stop stuff in to kill all except two programs. I came up with the idea of a Kill-All-Programs with Exception-list and should only be able to use the instruction in $Main.
Good idea. We already have a HALT, which halts a specific PROGRAM or TASK code-block.
So HALTALL would halt ALL PROGRAMs and TASKs, except for all the system tasks (e.g. $Main, $tTopOfScan, $t1Second, etc.), and also except for any other specified USER PROGRAM and/or TASK code-blocks (variable list).
And like you stated, HALTALL would only be available from $Main.
-
+1 haltall
-
Yes, this would be very helpful!
Instruction request!
After hard-coding all the E-stop stuff in to kill all except two programs. I came up with the idea of a Kill-All-Programs with Exception-list and should only be able to use the instruction in $Main.
Good idea. We already have a HALT, which halts a specific PROGRAM or TASK code-block.
So HALTALL would halt ALL PROGRAMs and TASKs, except for all the system tasks (e.g. $Main, $tTopOfScan, $t1Second, etc.), and also except for any other specified USER PROGRAM and/or TASK code-blocks (variable list).
And like you stated, HALTALL would only be available from $Main.
-
I already thought of having Task included in the HALTALL (Kill-All-Programs) but figure if the task is running in a program other than $Main, it to would be halted also. It wouldn't hurt to have it in also.
-
I think I've run into a bug in the Designer (1.4.3)
When you close a PID View or the PID Overview, any other PID Views open will stop recording the trend line. You have to close all of them and reopen them again to get them to restart.
-
I think I've run into a bug in the Designer (1.4.3)
When you close a PID View or the PID Overview, any other PID Views open will stop recording the trend line. You have to close all of them and reopen them again to get them to restart.
I was able to duplicate it. We will look into it. Sorry about that.
-
I've been watching PID views little more and found other minor issues.
If you don't have the PID view maximized (have it windowed) with the Data Form showing and then open another PID view, in the new PID window the Data Form will not be shown. Turning off and then back on the Data Form using the button fixes it.
One other issue I had was if I close a project with PID view open, the next time I try to open the project it pops up a dialog to select a PID loop and freezes there. Status updates still occur in the background but the mouse is the spinning "wait" cursor and the designer seems stuck. If you right click the designer icon on the taskbar and click "Close window", the designer will begin responding to mouse input again.
Another tiny error I just edited this to add. If you have 2 PID views open and at different time scales then select Sync on one and sync to the other, it will sync OK and the text for the time scale will change correctly but the slider will stay at the old scale. Very minor bug.
-
Anyone else need more room for their tag names? I am a little verbose in my naming and I am always trying to shorten the names due to character limits.
Would that be hard to expand?
You would not have to display the entire string in the ladder view just the first 16 characters like present. You could display the full name on mouse hover though..
-
Yes, This has been requested by many of us, and I believe Host has it in the pipeline...
-
Yes, This has been requested by many of us, and I believe Host has it in the pipeline...
...for 2.0.
-
Question: How hard would it be to add some formatting functionality to the comment editor? I've only done half a dozen PLC projects here at work, so take this with a healthy grain of salt. I'm sure that my experience is like many others here in that the work ends up getting reviewed by (and requires approval from) people who wouldn't know a ladder diagram from a step ladder. Because of this, I always try to make my comments as ELI5 as possible. I often find myself wishing there was a way to highlight a certain phrase or word in order to make it stand out. The CLICK comment editor has Bold, Italic, and Underline as well as color options, which in my limited experience has been more than sufficient. You wouldn't even necessarily need buttons on the editor window. If the editor was able to process some sort of basic markup instructions with an accompanying help file topic that would serve the purpose.
-
Question: How hard would it be to add some formatting functionality to the comment editor? Bold, Italic, and Underline as well as color options, which in my limited experience has been more than sufficient.
This is definitely on our TODO list.
-
Idec has that too. One of the few nice things about their controller/software.
BTW, why are people who can't read ladder "reviewing" your program? What is it they think they're going to find out? That makes about as much sense as me "reviewing" a document in Swahili by staring at it uncomprehendingly. Why not just make a separate document intended for non-engineers that explains whatever aspects of it they're interested in?
-
Oh there is always a written design specification, as well as user requirement and functional requirement specifications for all projects. That said, a printed copy of the ladder goes into the installation qualification data pack. It gets scrutinised by reviewers in the engineering, technical services, and quality assurance departments. Heck even a senior management executive gets a crack. I argue with my boss about it. I say "What are they reviewing, they don't even know what they are looking at?" His response is always, "That's why you comment it to death". The CEO puts it best. When questioning subject matter experts, he says, " If you can't explain it so that I can understand it, then you don't understand it well enough yourself."
-
I argue with my boss about it. I say "What are they reviewing, they don't even know what they are looking at?" His response is always, "That's why you comment it to death".
Still seems like an odd way to go about it to me vs. having a separate document aimed at their areas of interest. Why would they insist on looking at the actual ladder logic document? If you end up putting in more, and more verbose, comments than you'd want for yourself or another controls engineer, it just clutters up your view of the ladder, and the ladder definitely clutters up what they're trying to digest. Weird that they'd insist upon doing it this way.
The CEO puts it best. When questioning subject matter experts, he says, "If you can't explain it so that I can understand it, then you don't understand it well enough yourself."
I've heard that before, and I believe there's a degree of truth in it, but not to the degree people think. It's a handy principle that I'll have to remember next time I'm listening to Stephen Hawking talk. If I can't follow him, I'll just assume HE'S the problem and doesn't understand his subject matter!
*Not comparing either you or myself to Stephen Hawking, just exploring the validity of the CEO's belief.
-
You'd be amazed at the number of programs that I have worked on over the years that don't have a single shred of commenting. I would rather rewrite from scratch than to try to decipher someone else's logic.
At one point in my career I was put in charge of some junior programmers. They thought 5 lines of commenting was sufficient for a few hundred lines of code. That was when I started doing what Dean's boss does. "Give me the program when you think you are done with it", you'll get it back if I can't tell what the program does by reading the comments. Program quality improved significantly after that.
-
I might hide a little easter egg in my latest projects comments, see how carefully it actually gets checked. My boss will probably find it, If it catches his funny bone, he might just sign off and pass it along. He likes the old turboencabulator joke.
-
It's human nature. The closer physical proximity is to something, the higher probability that the association and relationship will be understood. If detailed design documentation is locked away in some office somewhere away from the PLC, MAYBE somebody will utilize it.
It'll be amazing, say in 2035, when you will be able to connect to a 20 year old Do-more PLC, where the PC where the original project existed along with any print-outs are sitting in some trash heap for 15 years. Regardless of the location of the DISK project, the Element Documentation and Rung Comments will be uploaded along with the control logic. And then even better, when the documentation explains why the program controls the system on a rung-by-rung basis, and not just re-iterating what the instructions do.
I started a new topic entitled Good PLC Program Documentation (http://forum.hosteng.com/index.php/topic,1684.0.html) for us to comment about this.
-
At one point in my career I was put in charge of some junior programmers. They thought 5 lines of commenting was sufficient for a few hundred lines of code. That was when I started doing what Dean's boss does. "Give me the program when you think you are done with it", you'll get it back if I can't tell what the program does by reading the comments. Program quality improved significantly after that.
Right, and that feels like about the appropriate level or a reasonable goal for how many and how verbose to make comments: so that another controls engineer can read it. Or, even not a controls engineer. I'm sure the mechanical engineer for the equipment, or the EE, if separate from the controls guy, or even a controls tech, should be able to figure it out from comments.
So I'm not arguing against documenting per se (although I try to get the code to do a lot of it for me via good synonyms, named constants, and point descriptions), but rather questioning whether IN the PLC program is the optimal location for storing a description intended for non-technical people.
-
When it comes to troubleshooting and documentation, I've stuck with the KISS principle. I keep the code as simple as I can. With the options of Tasks and Programs, this makes it so easy.
Program documentation is a great idea and I always comment and explain my code in the ladder logic.
For the non technical people in our shop and the maintenance personnel, we started installing HMI's anywhere we use a PLC. The small cost investment pays back dividends when it comes to downtime. All of our screens will show inputs / outputs (labeled to what they are) in addition to the readouts that the machine uses. All of our larger 8" displays have a big HELP button for operators and maintenance, it gives a flow chart to show what is missing from the sequence to run the machine.
-
Yeah, HMI's a BIG help in downtime troubleshooting. I do the same thing you do with the I/O. Another cool thing with some of the newer HMI's is that you can store good quality video, so you can shoot and put in multimedia lessons on how to operate the HMI and how to run the machine, in addition to hosting text and graphic help files there.
-
Feature request:
Could you make it so that the mouse scroll wheel will scroll the ladder tabs left and right when I'm hovered over them (Just like Firefox browser)?
Also, The Paste function and the Accept function take laboriously long in a large program (45571/65536). Could you look into any optimizations to make this quicker?
Thank you!
-
Feature request:
Could you make it so that the mouse scroll wheel will scroll the ladder tabs left and right when I'm hovered over them (Just like Firefox browser)?
Also, The Paste function and the Accept function take laboriously long in a large program (45571/65536). Could you look into any optimizations to make this quicker?
Thank you!
Define "laboriously long"...
-
Define "laboriously long"...
For a paste: 2.5 seconds+ for a single rung. For F8 It is 1-1.5 seconds+ per rung. It doesn't sound like much when I'm sitting here typing this, but when I'm making major edits for an upgrade project, it eats a lot of time...
-
There is zero doubt in my mind that some of this could be optimized. Right now we are eyeballs deep in coding new poorly optimized features ;), but maybe we can take a look at that before we launch the next version. A new case Mark?
-
Already in there, but there isn't much room for "optimization". It's usually a diminishing returns - a ton of work and added complexity to get it from 1.5 seconds down to 1.2 seconds (for example).
I looked at this once before and it's one of those issues where big programs with lots of stuff require lots of processing. I will definitely look at it.
-
Thanks guys. I wasn't trying to push things, but wasn't even sure if you were aware of the issues that are only evident in larger projects.
Do-more rocks!
-
Thanks guys. I wasn't trying to push things, but wasn't even sure if you were aware of the issues that are only evident in larger projects.
Do-more rocks!
Not trying to push things?!? Isn't that sorta, kinda, totally your MO? ;D
-
I certainly push the hardware and software, I just don't mean to push you! ;D
-
For F8 It is 1-1.5 seconds+ per rung.
Just found some debug code that is in production. Once we eliminate that, this should help F8-Accept.
-
Just found some debug code that is in production. Once we eliminate that, this should help F8-Accept.
Cool beans! ;D
-
We have installed 20+ Do-Mores and they are great! We have used the 205 series since their introduction in the mid-90s and you guys hit the mark with the Do-More covering all of our long standing "wish lists" for the 205 series. As always, AD and Host are the best by leading the pack with product development, technical support and price. With Do-More and Do-More Designer I have no idea why anyone would use any other product. We have been encouraging many of our customers to begin converting their existing high priced, outdated, and poorly supported AB, GE and other PLCs over to the Do-More. Several of our customers are big GE users and when they see what the Do-more can do, how easy Do-More Designer is, how inexpensive the hardware is and the software is FREE they are taking a hard look at their future. My personal recent experience with paying $1800.00 for the GE Proficy programming software, it taking 3 weeks to get permission to download it, then spending 3 hours on the phone with over half a dozen GE technical support guys just to get it downloaded, ensures I will always be a loyal AD and Host customer!
KEEP UP THE GREAT WORK!
-
OBSERVATIONS - Do-more Designer 1.3.1
Why are all the items in the Project Browser that you can't do anything with, e.g. Memory? Right click context for them is just generic with too many items anyway. A double click just takes you to the top of the tree. A double click should maybe take me to the configuration for that memory block.
Commenting in another post on the issue of not being able to find answers to previous questions, I finally ran into this one from Reply #274 on: 2014-05-15, 12:00:59. I can't find where this was ever answered and I was trying again today to see what this does. I can't even copy anything from that to use elsewhere. Am I missing something?
I am looking forward to DmD 2.0 to see what goodies we will find.
-
OBSERVATIONS - Do-more Designer 1.3.1
Why are all the items in the Project Browser that you can't do anything with, e.g. Memory? Right click context for them is just generic with too many items anyway. A double click just takes you to the top of the tree. A double click should maybe take me to the configuration for that memory block.
Commenting in another post on the issue of not being able to find answers to previous questions, I finally ran into this one from Reply #274 on: 2014-05-15, 12:00:59. I can't find where this was ever answered and I was trying again today to see what this does. I can't even copy anything from that to use elsewhere. Am I missing something?
I am looking forward to DmD 2.0 to see what goodies we will find.
I wasn't involved in the project browser development, so Franj will have to comment on this, but I think primarily it is there to provide a place to browse the system config contents. I would agree that the desired double-click action would be to open up the memory config, and that doing nothing isn't particularly helpful. ;)
-
Why are all the items in the Project Browser that you can't do anything with, e.g. Memory? Right click context for them is just generic with too many items anyway. A double click just takes you to the top of the tree. A double click should maybe take me to the configuration for that memory block.
Double click in a tree control is typically used to navigate the tree. However, we can add an option (like we do with the code-blocks) on double click behavior (since this was the original intent of the "Code-Block" browser, but became the "Project" browser). They are there to provide a simple mechanism to see the data type and sizes of every memory block and heap-item through a "browse" mechanism. Very powerful.
Anyway, possible options when double-clicking on Memory locations are:
1. Open the Memory Configuration for THAT block
2. Open a Memory View for THAT block
3. Open the Memory Image Manager for THAT block
4. Open the Memory Image Data Editor for THAT block
5. ?
We can definitely add a prompt to ask you which one you want to do on a double-click, then also let you have a configurable "default" behavior for double-click. We can add other possible "double click" behaviors as the need arises. You said that you are using 1.3.1, not 1.4.1, so you do not know what Memory Views or Memory Image Data Editor are. They are quite useful.
-
Why are all the items in the Project Browser that you can't do anything with, e.g. Memory? Right click context for them is just generic with too many items anyway. A double click just takes you to the top of the tree. A double click should maybe take me to the configuration for that memory block.
Anyway, possible options when double-clicking on Memory locations are:
1. Open the Memory Configuration for THAT block
2. Open a Memory View for THAT block
3. Open the Memory Image Manager for THAT block
4. Open the Memory Image Data Editor for THAT block
5. ?
We can definitely add a prompt to ask you which one you want to do on a double-click, then also let you have a configurable "default" behavior for double-click. We can add other possible "double click" behaviors as the need arises. You said that you are using 1.3.1, not 1.4.1, so you do not know what Memory Views or Memory Image Data Editor are. They are quite useful.
Actually the quote was from nearly 2 years ago, so I am using 1.4.3.3 now! I am keeping up this time.
As far as what it should do in the Project Browser, I'm open. What it would be preferable for it NOT to do, is lead me off every so often trying to discover what it is SUPPOSED to do. I forget in between times, and it's not in the help.
-
At some point it would be really nice to see the Comms server updated so that connections can be managed better. Of course it's way better than RSLinx right out of the box but still has some weaknesses. Being able to re-order them and maybe having a wider or full-page table format Link Selector and Editor/Configurator wizard (i have a strong distaste for dialog boxes that aren't resizable). Either that or integrated as a tearoff child window in Designer. And when a Designer crashes you need to Task Mgr in order to shut it down quite often. Additionally, it'd be wonderful to have some kind of enhanced network discovery in there as well. I'm rambling here but basically asking for a DSLaunch on steroids to support the Do-More series.
To answer the original question though the overall experience has been 4/5 not 5/5 partly for the reasons mentioned above.
-
I just installed it in a directory other than its default directory and I can not save or create a file because it is looking for the default directory location for the projects. I had to create the default directory tree it was looking for and copy the project directory over there to get it to work... Defeats the purpose of letting me chose the location.
-
I just installed it in a directory other than its default directory and I can not save or create a file because it is looking for the default directory location for the projects. I had to create the default directory tree it was looking for and copy the project directory over there to get it to work... Defeats the purpose of letting me chose the location.
Sounds like an install bug. It's an easy fix. The project directory is specified in the INI file, just edit it to what you want it to be.
-
Where is that ini file located? I cheched all of the install directories and can't seem to find it.
-
Open DMD. The file can be found in the Launchpad under the applications tab.
-
Open DMD. The file can be found in the Launchpad under the applications tab.
Yes!
The original file is in the Windows folder, however...
Due to security reasons, the OS keeps the actual modifiable copy in an invisible folder structure under your user account. The "DmDesigner.ini" entry in the Launchpad's Applications group is a batch file to locate that actual file and load it in Notepad automagically so you can modify it.
The one in Windows is just a placeholder for the OS but is not used by the executable.
-
Is it possible to make the force element dialog popup in the force value field rather than the element field?
I usually get there by right-clicking the element in a data view so I've already established the context of which element I want to force.
I've been unable to reprogram myself to select the value box every time and usually wind up overwriting the element name, having to cancel, and then slowing down and trying again. ;D
-Will
-
Is it possible to make the force element dialog popup in the force value field rather than the element field?
I usually get there by right-clicking the element in a data view so I've already established the context of which element I want to force.
I've been unable to reprogram myself to select the value box every time and usually wind up overwriting the element name, having to cancel, and then slowing down and trying again. ;D
-Will
Doesn't sound hard...
-
Generally very good. I would like to see a couple changes. The most important and simple would be to copy the Timer and Counter descriptions from the Timer or Counter to the timer .Done, .Acc... and other contacts so we do not have to write them or copy them twice.
You could do this a couple different ways like only copy 1 time when the description is entered. Or you could always copy if no individual description was added for say the .Done contact.
Second, Be able to manually configure the I-O cards so each slot can begin with a multiple of 10 like 10, 20, 30... This would make it much easier because then say the 7th lighted input or output would be 17, 27,37...
-
The most important and simple would be to copy the Timer and Counter descriptions from the Timer or Counter to the timer .Done, .Acc... and other contacts so we do not have to write them or copy them twice.
You could do this a couple different ways like only copy 1 time when the description is entered. Or you could always copy if no individual description was added for say the .Done contact.
We actually do some of this for the nickname, inheriting the nickname of the entire structure for individual fields. We do not do that for ExtraInfo or Description. Don't think it would be that hard actually.
Second, Be able to manually configure the I-O cards so each slot can begin with a multiple of 10 like 10, 20, 30... This would make it much easier because then say the 7th lighted input or output would be 17, 27,37...
Would be great, but this one is more problematic. Data needs to remain byte aligned for a number of reasons.
-
Loving the new 'Copy' command!! :D
How about a column chooser for the opening 'select project' screen??
'Last Opened' is not near as useful to me as 'Last Modified'.
Keep up the good work!
Will
-
How about a column chooser for the opening 'select project' screen?? 'Last Opened' is not near as useful to me as 'Last Modified'.
It would actually be easier to just add "Last Saved" as another column (the column headers are clickable to sort on other columns, and it remembers your last "column sort" setting).
-
I think your poll question about using Do-More needs another answer choice: "Already gave my left nut to AB and might not get it back."
-
I think your poll question about using Do-More needs another answer choice: "Already gave my left nut to AB and might not get it back."
Eh, only takes one, and now they are only half as likely to get you in trouble. ;)
-
Thermforming systems upgrade success :)
I successfully upgraded a http://tslusa.biz/en thermformer bought at auction and thrown in my lap and then the machine helped save lives!
I started out learning with the Click product line with a corrugated paper winder
Then I went to a strawberry basket stacker stepper 3 axis servo stepper
Then they gave me a project to run servos generating 380,000 pounds of force that form the plastic clam shells that hold fruit in grocery stores
When Covid-19 hit America they starting producing respirator masks on the production line
Its cool when you can directly help people stay alive
-
Great!
-
Great!
What was great?
What was "not so great"?
-
My first PLC Project used a Unitronics All-In-One HMI PLC for controlling six chemical metering pumps with open-loop-vector VFDs/motors. Positive displacement pumps had to range from about 30mL/min up to 20L/min and had to follow a master pump/flow for proportion and mixing. Also had to record and save the data to a memory card in a CSF format and be able to export it into a spreadsheet for later viewing.
Second project was using multiple Click PLCs in a LAN for controlling various chemical blending/pumping/transfer functions via ModBus TCP.
Third project was to build and control an XY positioning system with sixteen (16) axes. Thought I was going to use a Click PLC, but there was no motion control available for it. Also, I had started reading about Stage Programming and really liked it, so I used a BRX PLC with the native HSIO4 Motion Control Cards. Ended up networking two (2) BRX with four (4) HSIO4 Cards each, with a CMore Touchscreen for input of positions and saving "Jobs". All this was controlling sixteen (16) Tecknic ClearPath SDSK Step-and-Direction Servo Motors running precision lead screws.
Forth project was the build and control a twelve (12) axes XY positioning system. I used the same BRX and CMore as the previous job, but used the Teknic ClearLink Step-and-Direction Motion Control Modules, instead of the HSIO4 Cards. Much less wiring. Mostly all Ethernet Cables. ClearLink also provided remote I/O. Communication was through Ethernet IP and Explicit Messaging. THAT was very challenging for me, but I learned it and got it to work... but it was VERY tedious.
Current Project is to build and control two (2) YZ Pick-N-Place Robots for a case packing operation. Again, we will be using the ClearPath SDSK Servo Motors and ClearLink Step/Direction Controllers, Ethernet IP LAN and CMore Touchscreen. Will also be controlling conveyors and other material/product handling operations in the Robot Work Cell. Later, we will build/add an XYZ PNP Gantry Robot to do palletizing of the final, finished cases. All I will have to do is to add another ClearLink Unit to the Network for the XYZ ClearPath SDSK Servos and another Program in the BRX! :D Being able to have multiple programs that I can turn on and turn off, along with Sub-Routines (mainly for Math Functions) and Stage Programming is AWESOME and POWERFUL! (I still haven't quite figured out "Tasks", but we'll see. :) ) However, in addition to all of the above, I am extremely excited about the upcoming IMPLICIT ETHERNET IP MESSAGING SCANNER capability. If not for this, I would have to go with the Productivity Series of PLC. No way am I going to attempt Explicit Messaging for this project. Also, ClearLink already has an EDS File for the Productivity Series, that BobO is looking at for the BRX and may use it for testing the BRX Implicit Messaging.
To summarize, I love the Do-More Programming Language/Structure/Layout, Stage Programming Capability, Do-More Protocol for the CMore HMI, FREE Software and Support from Automation Direct and Host Engineering, Cost-Effectiveness, Soon-To-Be-Released IMPLICIT MESSAGING SCANNER function and the Speed of the BRX PLCs.
Thank you Host Engineering and God Bless!
SOWEGATS
-
...(I still haven't quite figured out "Tasks", but we'll see. :) )...
There are some animated PowerPoint slides I used to train the AutomationDirect techs on Do-more PLCs. You can download them and watch them. One is on Programs versus Tasks. To access:
- Goto https://www.hosteng.com
- In the left pane, underneath Training Slides, click on All Do-more PLCs
- Scroll down until you see #7, which is Programs VS Tasks
These are animated slides, so do a slide-show because they will not print very well.
-
There are also SUBROUTINEs that can be CALLed in-line (think MATH on steriods). You can pass "parameters" in and out, great for simple ladder logic that is re-used.
-
There are also SUBROUTINEs that can be CALLed in-line (think MATH on steriods). You can pass "parameters" in and out, great for simple ladder logic that is re-used.
Yes. I mentioned this above, unless I am misunderstanding you. I wrote subroutines to do positioning/step conversion and readout/display math. I called them only as needed, when an axis was moving.
Thanks and God bless!
SOWEGATS
-
...(I still haven't quite figured out "Tasks", but we'll see. :) )...
There are some animated PowerPoint slides I used to train the AutomationDirect techs on Do-more PLCs. You can download them and watch them. One is on Programs versus Tasks. To access:
- Goto https://www.hosteng.com
- In the left pane, underneath Training Slides, click on All Do-more PLCs
- Scroll down until you see #7, which is Programs VS Tasks
These are animated slides, so do a slide-show because they will not print very well.
Thank you, Greg!
I will definitely take a look.
Best Regards and God bless!
SOWEGATS
-
The Do-More platform is great :) Transparent, easy to work with, useful special functions, good communication capabilities etc. And one of the best things is that you don't feel left alone with your challenges. The support from Host Engineering and this forum is extremely valuable!
The only thing that is not great is the PID View Time Scale scrollbar ;) Having a longer scrollbar would make the time scale selection easier, there is plenty of space for a longer scrollbar.
-
The only thing that is not great is the PID View Time Scale scrollbar ;) Having a longer scrollbar would make the time scale selection easier, there is plenty of space for a longer scrollbar.
Fixed in Designer 2.11
see item 7.c in Updates.pdf (http://forum.hosteng.com/wndm/Updates.pdf)
7. Adjusted Anomalies c. Trend/PID View - widened Period slider on toolbar so detents are more obvious (6889, thanks to KH);