Version 1.4 loaded

[BobO]

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.

[Controls Guy]

I bet I barely notice this with all the cool new stuff, especially memory view!

[Garyhlucas]

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.

[BobO]

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!

[franji1]

Here's the link to Automation Direct's download page for Designer 1.4:
http://support.automationdirect.com/products/domore.html

[Garyhlucas]

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!

[franji1]

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.

[franji1]

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").

[Garyhlucas]

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.

[BobO]

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.

[BobO]

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.

[Garyhlucas]

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.

[b_carlton]

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.