Implicit I/O messaging

[SOWEGATS]

Thanks BobO!!  I really appreciate all the help!!

Many Thanks and God Bless!

SOWEGATS

[Scooter]

First I want to say thanks for getting this update through. I've been looking forward to it for some time. Now that I've got it I thought I'd begin by trying to integrate a Keyence X100W barcode scanner into a new fixture that I just started. I've used this scanner before in a project and was able to get it to function using the explicit ethernet I/O capability only. The Keyence user manual is pretty detailed in how to communicate with the scanner and they also provide an .eds file so I though that this would be a good place to start.

After selecting Class 1 for my first I/O message, the first issue that I ran into was in trying to create a Assembly Specific UDT structure. I was told that the maximum UDT length is 256 bytes but the Assembly is 1400. I thought that this was a bit strange since the number shown in the Count field (T->O) was set to 172 although it did also show that it could be set from 40 - 1400 bytes. I ended up modifying the .eds file to limit the size of the Result Data parameter to 128 bytes. This parameter is the last one in the structure and is used to store the actual barcode value scanned. I'm never going to be reading a barcode larger than 30 bytes so this should give me some buffer to work with.

So now I was able to begin creating my UDT structure by filling in the UDT field names for all of the parameters. One of the things that threw me off was when I hit the OK button before completing all of the fields of the table. This brought me back into the Create Connection Point Data window. If you hit the + key again to get back to the Create Assembly Specific UDT you are presented with a box where everything is blank again and I thought that I lost all of the data that I had just entered. At this point I believe that you are creating a new UDT structure but you need to cancel out of that box and then press the OK button to complete the connection point even though you are not finished yet. Once I did this, I was able to go back and edit the structure by hitting the button with the 3 dots. Is that behavior a bug in the program?

The next issue I had was when I finished filling out all of UDT field names in my structure. I realized then that there was no parameter  listed for the Result Data field?!? It wasn't in the list imported by the software. What the...?

So after some experimentation I found out that if I made the size of Result Data parameter (Parameter 1440 in the eds file) 32 or less, I could get that field to show up in the Create Assembly Specific UDT box table. This is puzzling because it is showing up as size xx bytes <Multi-Bit> in the table but I'm setting the value in the eds file based on bits. Of course this isn't going to help me as I need at least 1024 bits (128 bytes) of storage area for the scanned data.

So my question would be, why is this field not showing up in the list of parameters if the size is greater than 32 bits (as defined in the eds file)?

[BobO]

So now I was able to begin creating my UDT structure by filling in the UDT field names for all of the parameters. One of the things that threw me off was when I hit the OK button before completing all of the fields of the table. This brought me back into the Create Connection Point Data window. If you hit the + key again to get back to the Create Assembly Specific UDT you are presented with a box where everything is blank again and I thought that I lost all of the data that I had just entered. At this point I believe that you are creating a new UDT structure but you need to cancel out of that box and then press the OK button to complete the connection point even though you are not finished yet. Once I did this, I was able to go back and edit the structure by hitting the button with the 3 dots. Is that behavior a bug in the program?

It isn't a bug, but I can understand why it might be confusing and/or frustrating. Nothing below the + or ... is part of the adapter config, it is memory config. Rather than make you leave the adapter configuration to do your memory operations, we allow you to access it where more convenient. Anything with a + is about creating a new memory item, and all of those operations must be atomic before using them in the adapter config. Realizing that users may want to edit the UDT after the fact, we debated the best way to do that. The two possible answers were to do so through the UDT facility or to re-enter through the adapter config. We chose the latter, but chose to use the ... to differentiate from the initial creation, since at that point you are modifying a type that could have wide ranging implications. You can also access existing ASUDTs from the Manage Assembly Specific UDTs button on the Scanner config page.

The next issue I had was when I finished filling out all of UDT field names in my structure. I realized then that there was no parameter  listed for the Result Data field?!? It wasn't in the list imported by the software. What the...?

So after some experimentation I found out that if I made the size of Result Data parameter (Parameter 1440 in the eds file) 32 or less, I could get that field to show up in the Create Assembly Specific UDT box table. This is puzzling because it is showing up as size xx bytes <Multi-Bit> in the table but I'm setting the value in the eds file based on bits. Of course this isn't going to help me as I need at least 1024 bits (128 bytes) of storage area for the scanned data.

So my question would be, why is this field not showing up in the list of parameters if the size is greater than 32 bits (as defined in the eds file)?

At the present, Do-more doesn't have the capability to embed an array into a structure. We have ideas of how to get there, but isn't trivial. We knew that there would be limitations in the ASUDT system, but the alternative was to not create it at all. I felt that it was preferable to provide a good answer for the 70-80% of cases that it could be used, rather than scrap the idea because we couldn't render embedded arrays. Our provision for multi-bit fields and unaligned WORD/DWORD fields was actually also a workaround, but embedded arrays was simply not possible at the present.

For your application, a simple buffer...the only option in many other products...is probably the best bet. Sorry that we were not able to do a better job for you.

[Scooter]

At the present, Do-more doesn't have the capability to embed an array into a structure. We have ideas of how to get there, but isn't trivial. We knew that there would be limitations in the ASUDT system, but the alternative was to not create it at all. I felt that it was preferable to provide a good answer for the 70-80% of cases that it could be used, rather than scrap the idea because we couldn't render embedded arrays. Our provision for multi-bit fields and unaligned WORD/DWORD fields was actually also a workaround, but embedded arrays was simply not possible at the present.

For your application, a simple buffer...the only option in many other products...is probably the best bet. Sorry that we were not able to do a better job for you.

Thanks for your candid answer. No apologies needed.

I've gone through and tried importing the eds files from four other devices and have found that on all of those I'm not even given the choice to try to create a single structure. The option is greyed out. There must be something in those files that you guys don't like. Can you provide any insight to that?

And lastly, is it possible for those situations that I create my own UDT structure independently and just reference the heap item that I created for that UDT structure in the Local Addr: field in the T->O or O->T sections?

[BobO]

I've gone through and tried importing the eds files from four other devices and have found that on all of those I'm not even given the choice to try to create a single structure. The option is greyed out. There must be something in those files that you guys don't like. Can you provide any insight to that?

You can post them here and I can take a look. Most likely they are using some variant of array type memory, which we can't handle.

This stuff is always tradeoffs. We have made the mistake in the past of not offering a function because there were exceptions we couldn't handle. We eventually learned that something was better than nothing, even if it wasn't everything. The structure support is less complete than we'd like, but it works quite well for enough applications that we wanted to include it.

And lastly, is it possible for those situations that I create my own UDT structure independently and just reference the heap item that I created for that UDT structure in the Local Addr: field in the T->O or O->T sections?

Absolutely. It's just memory at the adapter level. ASUDTs are special and have magic driver code for unaligned and multi-bit, but everything else is treated a simple buffer.

[willpoll]

Just want to confirm, is there no chance this will ever be made to work on H2-DM1E CPUs?

Thanks!

[BobO]

Just want to confirm, is there no chance this will ever be made to work on H2-DM1E CPUs?

Thanks!

I wouldn't say no chance, but it isn't a high priority. We're out of storage space for the OS in both Terminator and H2, so we're having to be very selective about what we add. There are likely ways around that, but it isn't trivial.

[rlp122]

Just want to confirm, is there no chance this will ever be made to work on H2-DM1E CPUs?

Thanks!

Not that I have any say in any of this anymore, but from a business development perspective there isn't any value add for this feature in those old systems other than backwards compatibility.  If it were me making this decision and it's not, I wouldn't waste precious development resources.  I would look to the future and work on something more powerful than BRX. 

Just my two pesos.

[Controls Guy]

Absolutely agree, rlp122

[BobO]

We're getting serious about the DM2 now. Spec-ing parts as we speak. Initially on BRX hardware, but expanding to a bigger brother soon after.

[willpoll]

A H2-DM2 would be awesome! 

I do like the BRX, but I prefer the DL205 form factor.

Cheers!

-Will

[BobO]

A H2-DM2 would be awesome! 

I do like the BRX, but I prefer the DL205 form factor.

Cheers!

-Will

The bigger brother to BRX I referenced will be rack based. The 205 backplane isn't going away anytime soon, but we'd like to have a higher performance and more modern alternative.

[SOWEGATS]

Hi BobO!

Which command uses less network bandwith when reading/writing data to the input/output assemblies: Publish & Subscribe or Copy?

Also, Regarding the Teknic EDS File:

1) The Configuration Assembly imported and "formatted" just fine.  I.E. It made a UDT(?) with labels on its own, correctly with the proper labels for each memory location;

2) The Output and input assemblies were both too big for automatic or manual setup of UDTs, because they are both bigger than 256 Bytes.  Also, I could not modify the EDS, because it would have changed the index #s of the registers, and Teknic strongly advised against that. Howerver;

3) I was able to set up custom Memory Blocks (332 Bytes for the Output Assembly [named ROUTB] and 280 Bytes for the Input Assembly [named RINB]) and they are correctly indexed to the actual Tecknic Output and Input Assemblies, with no offset!     E.G. For the Output Assembly, Teknic Documention shows Bytes 24-27 as the Move Distance Registers/Bytes... This corresponds EXACTLY to ROUTB24-ROUTB27, and I Publish or Copy values into those Registers as a Signed DWord.

4) Only real problem I have is that the Enable bit for the motor is dropping out randomly, but re-establishing so quickly that I cannot catch with the PLC (faster than the BRX Scan Time, but slow enough to shutdown the motor).  Is there a network buffer that is causing this?  Or a network speed (200 packets/sec) - vs - PLC Scan Time issue?

Thanks and God Bless!

SOWEGATS

[SOWEGATS]

Hi BobO!!

Please see my post above, from yesterday.

Many Thanks and God Bless!!

SOWEGATS

[BobO]

Hi BobO!!

Please see my post above, from yesterday.

Many Thanks and God Bless!!

SOWEGATS

I've been out this entire week with COVID. I'll see if I can get someone else to answer your questions.