Please tell us what your experience has been with Do-more...

[franji1]

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.

[plcnut]

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?

[franji1]

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

[Controls Guy]

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.

[Controls Guy]

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?

[BobO]

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.

[BobO]

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.

[Controls Guy]

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.

[Controls Guy]

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

[BobO]

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.

[plcnut]

Use SL instead of SS, or better yet make your own String heap item or an array at 1024 Characters.

[BobO]

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.

[BobO]

Use SL instead of SS, or better yet make your own String heap item or an array at 1024 Characters.

What he said.

[Controls Guy]

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!!   

[Controls Guy]

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