Modbus Scanner Request

[RBPLC]

Would be nice to be able to use the Modbus scanner in conjunction with UDT structure members (specifically strings). Would like to be able to read from a continuous block (say 20) of 16-bit integers representing ASCII characters and send them directly to UDT.String as a text string.

[BobO]

Would be nice to be able to use the Modbus scanner in conjunction with UDT structure members (specifically strings). Would like to be able to read from a continuous block (say 20) of 16-bit integers representing ASCII characters and send them directly to UDT.String as a text string.

Can be used with UDTs, but not strings. I'd have to ponder a bit how to fit it in the architecture, but it might be manageable.

[RBPLC]

Additional Request:
Link or ability to modify UDT from the "Edit Modbus I/O Scanner Device" Window. This would allow the UDT to be built as you go along building a Modbus device without having to exit to get back to the UDT creation section. I suspect this is probably pretty difficult.

[BobO]

Additional Request:
Link or ability to modify UDT from the "Edit Modbus I/O Scanner Device" Window. This would allow the UDT to be built as you go along building a Modbus device without having to exit to get back to the UDT creation section. I suspect this is probably pretty difficult.

We are starting work on the instantiable program feature, and the data associated with each instance will be UDTs. Since nobody will like bouncing back and forth between coding and defining the UDTs, we are looking at making it possible to add new fields to existing UDTs without going into the UDT editor. We were already considering that people would want to do that other places as well. So maybe.

[RBPLC]

We are starting work on the instantiable program feature, and the data associated with each instance will be UDTs. Since nobody will like bouncing back and forth between coding and defining the UDTs, we are looking at making it possible to add new fields to existing UDTs without going into the UDT editor. We were already considering that people would want to do that other places as well. So maybe.

Please tell me that you guys are making some headway on this. The current UDT editor implementation is killing me. 3-4 windows to edit the UDT, 2-3 popups warning me about changing the UDT, rinse and repeat.

[franji1]

Please tell me that you guys are making some headway on this. The current UDT editor implementation is killing me. 3-4 windows to edit the UDT, 2-3 popups warning me about changing the UDT, rinse and repeat.

Yeah, it definitely was developed as a "batch" operation, not incremental.

It can definitely be streamlined if you don't care about memory layout or non-default display format, or even if you do, provide short cuts to the Add New Field dialog.  Also, we can add "don't notify me again" on the nag dialogs.  Those are definitely there for the person who is not fully aware of what is going on - but once you do - they get in the way.

Tell us how you are wanting/actually developing incrementally (code and/or heap/data-block and/or UDT definition) so we have a better idea of what would be a good UX.

[RBPLC]

1) I would say that my development style is incremental. Knowing the current pain of editing UDTs, I try to define most of the element members to start with. Once a system is commissioned, minor edits/improvements to a machine are probably fine using the current setup as you typically don't make many changes at once. This however is not the case when initially developing the control program for a new system.

2) When developing a program for a new machine, easy access to the UDT editor is a much bigger deal as you can't possibly think through all of the elements you might need. In my opinion, the UDT should be as easy to edit as any other pre-defined memory (C, T, D, V etc.).

3) Depending on the development difficulty, I recommend the following:

-Absolutely have the option of getting rid of the nag dialogs. I know that I'm changing the memory layout and I realize that it'll require a stop mode transfer and by the way I realize that status can't be displayed properly because I've changed the memory layout.

-At a minimum, provide a direct link to the "Structs" tab of the Memory Configuration. I don't need to click the Memory Configuration Shortcut and then the "Structs" tab. If possible, get me right to the UDT I want to edit.

-Ideally, the ability to edit UDTs needs to be in an actual window that can be separated from the development ladder code. I've posted about the same thing concerning the Documentation tab. In my mind, both of these things need to pulled out from the ladder section and need to be displayed on a separate monitor so that both ladder and memory elements can be edited at the same time. You absolutely need the ability to see both the Documentation and the UDTs on a separate monitor while also seeing your ladder code on the other. I still think that how it's done in TIA Portal is a good go-by. In Productivity Suite, it's not a stand alone window, but at least you can see your ladder and your Tag Database at the same.

-Put pre-defined filters into the Documentation Editor so that I can filter by memory type. A single flat listing of all memory elements is a pain. The recent filter addition helps, but ability to filter by memory type would be beneficial. Again, something similar to what's available in Productivity Suite.   

[Controls Guy]

We are starting work on the instantiable program feature, and the data associated with each instance will be UDTs. Since nobody will like bouncing back and forth between coding and defining the UDTs, we are looking at making it possible to add new fields to existing UDTs without going into the UDT editor. We were already considering that people would want to do that other places as well. So maybe.

If you edit a UDT in a way that makes it larger, and there are already instances with data in the members, do you have to reinitialize or does the data get moved in the.RPR mode transition?   Especially if there's a block of contiguous instances.  Can't remember how it works now, I think the data is preserved.

I often include spare space in the UDT so I'm not sure what the default behavior is.