Yaskawa JOHB-SMP3

We recently got in a batch of replacement network cards for Yaskawa VFDs.
The named model is “JOHB-SMP3”.

Sadly, this device does not appear to be a drop in replacement for the previous network card we are using.

The first thing I noticed is that the reported product code of the device seems to be a pass-through from the drive it’s attached to, but the revision number seems to go with the card.

This creates some challenges with NodeInfo.xml/CustomNodeInfo.xml.
The nodeinfo data I have for the old interface card doesn’t work with the new card.

IIRC, I’m not able to distinguish between devices that only differ by revision? Are there other workarounds that don’t involve manual customization by humans depending on which devices are in use?

You are correct, NodeInfo doesn’t support devices differing by hardware revision. This is a valid use case and we’ll investigate adding support.

What specific differences does this device have between revisions? If it’s not too much, perhaps you could massage the ESI file to make them more similar, as a short-term workaround.

The first obvious difference is in the PDO configuration. The PDO’s that I had set up (some added and removed content) doesn’t work for this device. When it’s “wrong,” the network won’t start.

What’s worse about this behavior from Yaskawa is that unless we can distinguish between these devices ENI configuration, it’s really going to break backward compatibility.
It also looks like the device has its own ESI file. Does RMP pay any attention to revision numbers when matching ESI devices?

So, I’m trying to hack the NodeInfo data to get all the objects I need for operation to be sent/received using the PDO channel.

#12 (X) 00:00:54.728 EtherCAT EcSlave.cpp:2002 ‘Box 3 (Yaskawa VFD)’ (1004) ‘PS’: CoE (‘InitDown’ 0x1c12:0) - SDO Abort (‘Value of parameter written too high.’, 0x06090031): ‘download pdo 0x1C12 count’.

Can you interpret this for me? Does this mean I have too many PDOAssignment elements for the device?

Hi @todd_mm,

We found that using revision caused way more headaches than not. It would force people to find updated ESI files to match the revision of the hardware they were using. ‘New Hardware that behaves the same = Broken System’ is not a good look. The vast majority nodes do not tend to change behavior with revision.

Unfortunately it looks like Yaskawa is leveraging revision to change behavior.

Yaskawa is also much more limited on PDOAssignments than most nodes. You typically have to remove something to add something because it only allows so many entries. The error you are seeing. Value too high on pdo count is an example of this. Can you send me the old/new ESI and old/new CustomNodeInfo.xml? I’ll take a look to see if I can make any suggestions.