I’m attempting to merge RSI 8.1.8 into our application. I noticed that, out of the box, the EtherCATNodeInfo.xml file doesn’t contain the right/enough info for digital inputs. At least, The digital input count is 0 and no inputs are shown under the IO tab.
I’m using the stock files from the runtime download.
Now, the previous setup I had (8.1.6) worked OK. I had some things different in my file. IDK which ones were operative for this difference in behavior.
My File (works for 8.1.6)
<PDOs>
<PDOAssignment Index="0x1601" IsOutput="True" Include="True" RemoveContent="0x6040 0x607A" />
<PDOAssignment Index="0x1a01" IsOutput="False" Include="True" RemoveContent="0x6041 0x6064">
<AddEntry Name="Digital inputs" Index="0x60FD" SubIndex="0x0" BitLen="32" DataType="UDINT" />
<!-- This is not mapped by default. -->
<AddEntry Name="Touch probe 2 position value" Index="0x60BC" SubIndex="0" BitLen="32" DataType="DINT" />
</PDOAssignment>
<PDOAssignment Index="0x1600" IsOutput="True" Include="True" RemoveContent="0x6060 0x6072">
<AddEntry Name="Physical outputs" Index="0x60FE" SubIndex="0x1" BitLen="32" DataType="UDINT" />
</PDOAssignment>
<PDOAssignment Index="0x1a00" IsOutput="False" Include="True" RemoveContent="0x6061">
<AddEntry Name="Velocity actual value" Index="0x606C" SubIndex="0x0" BitLen="32" DataType="DINT" />
</PDOAssignment>
</PDOs>
<IO>
<DigitalInputItems>
<!-- Specify your limits as a DigitalInput Attribute similiar to Size with Home="22" PosLimit="18" NegLimit="17"-->
<DigitalInput SigBits="0x007F0000" Size="32">2nd Transmit PDO mapping.DigitalInputs</DigitalInput>
</DigitalInputItems>
<DigitalOutputItems>
<DigitalOutput SigBits="0x000E0000" Size="32">2nd Receive PDO mapping.DigitalOutputs</DigitalOutput>
</DigitalOutputItems>
</IO>
Did you try just replacing the new implementation (Vanilla 8.1.8) with the old one? If not, you can try doing that. Then delete ESICache.xml. And try creating a new ENI file and starting the network again.
The XML from the 8.1.6 installation does provide inputs for the SDG7S with 8.1.8 software.
I’m trying not to maintain an entirely custom ENI XML and use the one that ships with the software, at least as much as possible.
You’ve got some settings in 8.1.8 that are different, and I’m not entirely certain which things I should adapt to your solution and which I need to maintain as customizations that we need to maintain.
Differences
I have the AddEntry[@Name='DigitalOutputs'] in 0x1601, whereas you have it in 0x1600.
Yours is named differently, probably reflecting what’s in the Yaskawa ESI file. I assume this is completely superficial and not really important.
My 0x1601 has [@Include='True'] but yours has [@Include='False']
My 0x1601 hase some @RemoveContent (to make room for the digital outputs, I think), and yours doesn’t.
I suppose this only maters if the AddEntry element is in 0x1601.
The IO/DigitalInputItems/DigitalInput[@SigBits] differs.
I have 0x7F0000, and you have 0x37F0000. The Sigma-7S EtherCAT manual I have [1] lists bits 0-2,16-22,24-25 as bits in the 0x60FDh object. Neither your mask nor mine account for all 9 of these, I suppose the --,++,home inputs are not in your mask. Correct?
The corresponding DigitalOutput [2] item has a different mask. I recall some experiments with the physical outputs resulting in a mask of 0xE0000 matching the three bits in question, though I don’t recall for sure. I’ll double check. In theory, E0000 corresponds to “bits 17-19.” Also, your mask only has two bits in it. Is there a reason why?
I tried moving the configuration over, and merge the two, but it wasn’t successful. I expected yours to work out of the box, but it didn’t, so I was apparently merging something incorrect.
I am not really getting any feedback from the tool, so I don’t know where things are going wrong.
I could just use my old version wholesale, or employ some voodoo and copy things without understanding why they matter. However, I’d prefer to understand how things are supposed to work so that I can make intelligent decisions in the future.
I tried to reconcile the differences between customer implementations before so no changes were needed. Unfortunately, there wasn’t a way to do so without breaking existing code. I can’t really change PDO entries and unless you are the only customer using the product.
The Sigma7 does not have fixed PDOs so we can adjust them however we like. We don’t really care which you use but you do need to update the associated Entry in the other part of the Device Entry.
Entries 1x00 will show up as 1st Transmit/Receive PDO mapping.
Entries 1x01 will show up as 2nd Transmit/Receive PDO mapping.
Entries 1x02 will show up as 3rd Transmit/Receive PDO mapping.
Entries 1x03 will show up as 4th Transmit/Receive PDO mapping.
As a side note, it does look like we have a mistake in vanilla. Since we have Digital Inputs on 0x1a01 it will appear as 2nd Transmit rather than 1st Transmit. I will correct this for the next release. I can also inject your Touch probe 2 position value as an additional PDO entry should be acceptable to anyone who didn’t hardcode their Network indexes. (Lets hope no one did.)
You are right. We used physical outputs rather than Digital Outputs as that is the describe in the CiA DS402 entry and Yaskawa manual for that sub index. I prefer Digital Outputs but I’m trying to keep to the standard. You could call it ~banana~ if you updated the associated Digital Outputs entry.
You actually stripped out the content out of 0x1601. So there is an exchanged empty PDO. I figured we just shouldn’t exchange it.
Since I removed the entry PDO I didn’t need to Remove Content the PDO entries from it.
I added 3 to the front of SigBits which is HWBB1 & HWBB2. These will likely be unused in most cases.
I was hesitant to include Home/POT/NOT as they should show up as Digital Inputs in the list. You can do so. Use 0x037F0007 (Or a sub string of it) to do so.
Here I suspect Yaskawa made a mistake in their manual. The pattern is skip the first 16 bits and start Digital I/O on the 17th one. I think they represents Digital Outputs on bit 17 forgetting that it was zero ordinate. There is no good reason to start on bit 17 rather than 16 that I can think of. I’ve only got 2 enabled. I think enabling 3 with a 7 is better.
Would you like additional information any part of this so you can better understand it?
Thanks for the detalis. I’m not necessarily expecting you to set vanilla/defaults in what you ship to match what we need. I’m attempting to adapt what you ship to what we need with a minimal set of changes, so these explanations are very helpful.
If you want to add touch probe 2 position, that would be great. I would sort of expect most people to want that, too.
Regarding outputs, I physically tested this once (upon a time) with Sigma-V and Sigma-7, and it think I remember (0-indexed) bits 17-19 corresponding to the various outputs. I understand why this would be counterintuitive. I was just going with what was the de facto behavior. YMMV.
You’re free, of course, to ship whatever you think is sensible for Yaskawa. You don’t need to customize it for my needs. Diff/patch isn’t particularly intelligent regarding XML, so it’s less of a headache to upgrade if the XML changes I need to make are small and simple.