Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Garyhlucas on July 07, 2015, 08:25:43 PM
-
Just installed 1.4. Wow lots of stuff in there! This product reminds me of Rhino 3D. It improved really fast with a very active newsgroup and most power users actually running beta code.
Thanks guys,
-
Just installed 1.4. Wow lots of stuff in there! This product reminds me of Rhino 3D. It improved really fast with a very active newsgroup and most power users actually running beta code.
Thanks guys,
Well I am feeling excluded. Some kind of Inside Track Member? :'(
-
No, 1.4.1 is the current DMD version linked on Host's main page. Must have just gone up in the last day or two. Been meaning to check and see when it was available! :)
-
Hmmmm... :(.....spoke too soon. The link says it's for v1.4.1, and the release notes show what's in it, but the linked page at ADC just shows 1.3.1. And...if you assume the naming convention for the files is consistent and the file is probably actually there and try to download http://ftp.automationdirect.com/pub/domore_v141.zip, it's not there.
-
I finally realized you just have to open DMD and it finds the updates and allows you to download and install. Just released today and I saw the same things you did.
Well crap. All of my customizations from 1.3.1 are missing in 1.4.1.
-
Ah OK, thanks!
-
Well crap. All of my customizations from 1.3.1 are missing in 1.4.1.
Sorry. All of the customizations are still possible, they just have to be set up in the new world. When we went to side-by-side installations, the INI files became version specific. Still, I thought we propagated stuff from one install to the next, but apparently not. Guess we can look at doing better on that in the future.
Hopefully the new 1.4 features will make it worth a few minutes of setting your world back up.
-
Oh, you're not kidding! The Memory view alone (and you rocked yours with tons of stuff AB's and Omron's versions don't do) would be worth setting things up again. Then being able to DEVWRITE POP server addresses is totally indispensable if you need it, and I do. Just reading through the release notes PDF. The EIP master and slave is huge, too. TONS of great stuff here. Thanks, Hosties!!
-
I noticed that the "Necessary-LD-ST1" issue has been slightly addressed (dialog message asks whether you want to add the thing or merge the rungs). I don't think this is as good as assuming an implicit one and not showing it. Is that still in the plans as was previously thought? I'd MUCH prefer that. Less keystrokes, less irrelevant stuff to read, and less screen clutter.
-
Having Print All not forget B/W setting is a biggie for me, too. Thanks! :)
-
I noticed that the "Necessary-LD-ST1" issue has been slightly addressed (dialog message asks whether you want to add the thing or merge the rungs). I don't think this is as good as assuming an implicit one and not showing it. Is that still in the plans as was previously thought? I'd MUCH prefer that. Less keystrokes, less irrelevant stuff to read, and less screen clutter.
Having an instruction that is there, but isn't there, until you really do need it to be there, etc, etc, becomes a bug trap. We wanted to deal with the issue, without creating five new ones. Perfect? No. But at least it doesn't do something without warning you, leaving you scratching your head.
-
Yeah, but I still have to look at the thing, which has no meaning. Just mental and visual clutter. I guarantee you not 1 in a 1000 people look at the ladder view as a 100% literal view of the stack instructions. I-Boxes are non-literal, this could be just as well.
Entering it was never the problem, looking at it was.
-
Well crap. All of my customizations from 1.3.1 are missing in 1.4.1.
Sorry. All of the customizations are still possible, they just have to be set up in the new world. When we went to side-by-side installations, the INI files became version specific. Still, I thought we propagated stuff from one install to the next, but apparently not. Guess we can look at doing better on that in the future.
Hopefully the new 1.4 features will make it worth a few minutes of setting your world back up.
I probably should have said "Well shoot" instead. I pretty much figured I would have to do them over from previous threads. I like how the toolbars are all up there from the get go. Quite frankly, the large icons really look nice and it's a shame I need the space for everything else a bit more.
I have to admit that while I have the same toolbar style on all three 1.3.1 installs, I didn't manage to get the buttons in the same place for any of them.
The real shame is I have to hit the sack as I have a long road trip tomorrow and I don't get to play with it. :(
-
Yeah, but I still have to look at the thing, which has no meaning. Just mental and visual clutter. I guarantee you not 1 in a 1000 people look at the ladder view as a 100% literal view of the stack instructions. I-Boxes are non-literal, this could be just as well.
Entering it was never the problem, looking at it was.
Having a single IBox represent n opcodes is easy. Having 1 opcode disappear when it should, and the same opcode not disappear when it shouldn't, is problematic. I know that you don't like it, I don't either. But I also know that you would like it even less if it became the bug trap it could be.
Put another way (and one of my favorite sayings here at Host) "I would rather apologize to 20% of the customers for what I chose not to do, than to apologize to 100% for what I did poorly".
And for what it's worth, we really didn't do it to solve the issue you are trying to solve. We did it for the new guy who has no clue what manner of witchcraft is sucking his stuff up into the previous rung. Meaning, we could keep a case around to revisit it in the future.
-
Having a single IBox represent n opcodes is easy. Having 1 opcode disappear when it should, and the same opcode not disappear when it shouldn't, is problematic. I know that you don't like it, I don't either. But I also know that you would like it even less if it became the bug trap it could be.
Oh I see, you're saying that people sometimes use a NO ST1 intentionally to jump around something, so now you'd have to check if it's the first opcode on the rung, etc., etc. Understood. Maybe there needs to be a new ST bit that's equivalent to ST1 and a LD STxx always disappears? If you put it in the middle of a rung, it turns into a wire and gives the short circuit error as if you'd drawn the wire manually? Or a new opcode like RSS (ReSet Stack), and ALL rungs start with it. That way the show/don't show decision doesn't become a dilemma.
And for what it's worth, we really didn't do it to solve the issue you are trying to solve. We did it for the new guy who has no clue what manner of witchcraft is sucking his stuff up into the previous rung.
The new behavior does address that scenario very well.
Meaning, we could keep a case around to revisit it in the future.
Thanks, that would be much appreciated!
-
Oh I see, you're saying that people sometimes use a NO ST1 intentionally to jump around something, so now you'd have to check if it's the first opcode on the rung, etc., etc. Understood. Maybe there needs to be a new ST bit that's equivalent to ST1 and a LD STxx always disappears? If you put it in the middle of a rung, it turns into a wire and gives the short circuit error as if you'd drawn the wire manually? Or a new opcode like RSS (ReSet Stack), and ALL rungs start with it. That way the show/don't show decision doesn't become a dilemma.
All that, and a bit more. Generating rungs from opcodes would be easy. Generating opcodes from rungs that were appropriately marked as being power rail connected is easy. Where it gets fuzzy is in the cutting/pasting/editing/merging/splitting/etc where we don't have either well formed opcodes or well formed rungs. Always knowing what was intended can be difficult.
If we were to do it, we would likely create a hidden $On variant like you suggested. I personally would love it and I think others would too. It just wasn't a super straightforward thing. What we ended up with was broke several times before it wasn't. ::)
-
I bet I barely notice this with all the cool new stuff, especially memory view!
-
Found some issues with 1.4. When going online with the PLC using Ethernet if the connection can't be made because say the IP address is wrong, the program hangs and doesn't stop trying. Hitting cancel causes the connection window to gray out and then the program doesn't respond at all. Using the three fingered salute and Task Manager to kill it leaves a window open that doesn't respond to anything. If you didn't save to disk all those little changes you were going to test, well they are gone!
When editing a rung and adding a contact into an existing second row the vertical wire no longer connects and you have to manually add a new one. Once you accept the change it comes out fine.
It would be nice if rungs that weren't full of objects actually had empty space between them to add additional contacts. The Insert column before or after stuff gets old quickly. Once the rung is full I am okay with needing to add a column.
Thank you for the fixing the sort in the documentation editor, and jumping to the tag field when inserting new tags! Saved me a lot of time already today.
-
Found some issues with 1.4. When going online with the PLC using Ethernet if the connection can't be made because say the IP address is wrong, the program hangs and doesn't stop trying. Hitting cancel causes the connection window to gray out and then the program doesn't respond at all. Using the three fingered salute and Task Manager to kill it leaves a window open that doesn't respond to anything. If you didn't save to disk all those little changes you were going to test, well they are gone!
I don't know of any changes to the comm server that might have introduced this, so it may have been present in previous versions. We have seen cases where (we suspect) VPN drivers can lock us down if networking attempts to use a disconnected VPN. We've been meaning to look into this, but it keeps getting kicked down the road.
When editing a rung and adding a contact into an existing second row the vertical wire no longer connects and you have to manually add a new one. Once you accept the change it comes out fine.
Not sure I understand; I don't remember it automatically adding a wire. Generally I do this by moving my cursor to the last output instruction on the rung, then Ctrl-Down Arrow.
We did add some smarts to prevent the next rung from automatically getting absorbed by the previous when there is no input logic. Is that what you are referring to?
It would be nice if rungs that weren't full of objects actually had empty space between them to add additional contacts. The Insert column before or after stuff gets old quickly. Once the rung is full I am okay with needing to add a column.
The next major release is almost exclusively dedicated to environment improvements. We'll add a case to look at that.
Thank you for the fixing the sort in the documentation editor, and jumping to the tag field when inserting new tags! Saved me a lot of time already today.
You're welcome!
-
Here's the link to Automation Direct's download page for Designer 1.4:
http://support.automationdirect.com/products/domore.html
-
Bob,
I wasn't saying the vertical wire was not being automatically added. What I was saying that the existing vertical wire got broken when a new contact got added into the existing second row of the rung. So you had to add a new one to replace it.
Found another bug. When a stage is created the automatic nickname generated contains a period which is an illegal character in a nickname. So if you try to edit the nickname you have to replace the period with an underscore or you get an error.
Getting a heavy does of programming right now!
-
What I was saying that the existing vertical wire got broken when a new contact got added into the existing second row of the rung. So you had to add a new one to replace it.
I sent you a private message on this. We could not duplicate it, but it's probably because we need more detail/info.
-
Found another bug. When a stage is created the automatic nickname generated contains a period which is an illegal character in a nickname. So if you try to edit the nickname you have to replace the period with an underscore or you get an error.
The "implied" nickname with a period is because you have a nickname for the structure (e.g. nickname "George" for the code-block MyCodeBlock), and so the nickname for the stage bit is the nickname for the structure followed by the ".S0", i.e. "George.S0". Yes, this is an illegal nickname, if you try to save it. Since it is an IMPLIED nickname, just don't try to save it. The key point here is that it is an "implied" nickname. You cannot actually save the "implied" nickname. However...
If you DO want to assign a different nickname other than the implied "George.S0", you can, but it must be legal (i.e. no periods, just letters/numbers/underscores, up to 16 characters, e.g. "StartOfGeorge").
-
I find it inconsistent to say a character is illegal in a field and then use that character in the field! Why not create the nickname following the rules explicitly, and use an underscore then when we want to change the nickname we don't also have to fix the illegal character. In my case I started editing the wrong nickname and the editor started barking that the nickname wasn't valid even though I didn't change it!
Consistancy is the mark of a true professional.
-
It's wrong. It was an oversight. It will be fixed. Mark was just explaining how it happened.
When you document the structure itself, but haven't documented a field, we automatically expand that into Nickname.Field when referenced in the program...what he was calling implied. When you start to edit the field's empty nickname, we are accidentally prefilling with the implied one rather than leaving it empty. We're calling the wrong function. Simple fix.
Sorry for the confusion.
-
I find it inconsistent to say a character is illegal in a field and then use that character in the field! Why not create the nickname following the rules explicitly, and use an underscore then when we want to change the nickname we don't also have to fix the illegal character. In my case I started editing the wrong nickname and the editor started barking that the nickname wasn't valid even though I didn't change it!
Consistancy is the mark of a true professional.
After digging a bit, it was added intentionally to make users aware of the implied nickname associated with a field once the structure itself has been documented. It has been that way since Do-more was launched and this is the first complaint we've received. One man's feature is another man's bug.
However, it was a simple thing to have the implied name removed from the editor at the start of the edit. This allows for both our intended behavior and your expected behavior...win/win.
-
I guess the reason it bugs me is because I am very conscious of the need to thoroughly document programs right from the start. So I work at having consistent nicknames and verbose descriptions for every tag. Years ago I had a young programmer writing code for me in assembler. I'd sit down and ask him to explain some of the code he had written. If he couldn't look at his comments and tell me instantly how it works then I'd stop him from writing any more until the documentation was done. McGraw Hill hired him away after four years. We turned the maintenance of the code over to another company and they were really pleased that it was so well documented. That saved us money too as they didn't just rewrite stuff they didn't understand. Later the young man told that my emphasis on documenting as you go really paid off for him in his new job. He was very productive because everything he wrote was easily reused.
In any event I greatly appreciate that you guys actually care. AB has paid tech support and doesn't fix known bugs for years. They are shipping CompactLogix processors with like 1.1 firmware when the current firmware is like 20.1! It takes a lot of time to update their firmware. Total BS.
-
In any event I greatly appreciate that you guys actually care. AB has paid tech support and doesn't fix known bugs for years. They are shipping CompactLogix processors with like 1.1 firmware when the current firmware is like 20.1! It takes a lot of time to update their firmware. Total BS.
Just as a note, AB deliberately ships the Control/Compact Logix CPUs with just enough 'smarts' to accept a firmware download. Just using the latest is not always the best option.