Hi, Jesper originally needed the patch due to his module requiring a 3kb SII (which he generated from the TwinCAT xml), but the module only had 2kb of memory. The patch loads the first 32 bytes of the xml: - alias - vendor_id - product_code - revision - serial number
from this it tries to find first a revision based file, then a generic product file - 1st: ethercat/ec_%08x_%08x_%08x.bin (vendor_id, product_code, revision) - 2nd: ethercat/ec_%08x_%08x. bin (vendor_id, product_code) The alias is read from SII, so that is fine. Revision specific SII's is also covered. If a file can't be found then the remaining SII information is read. I needed this patch due to our early Yaskawa amps having a faulty SII. The amp also did not allow new SII's to be uploaded. Downloading the SII from a newer amp and reading it from file for the older amp worked well. So the cases where it is needed is if the SII memory is not big enough, or the SII memory is faulty and the module does not allow new SII information to be uploaded. I have attached the patch. Regards, Graeme. -----Original Message----- From: Gavin Lambert [mailto:gav...@compacsort.com] Sent: Wednesday, 4 May 2016 11:13 a.m. To: Graeme Foot Subject: RE: [etherlab-dev] [PATCH] Default branch patchset On Wednesday, 4 May 2016 10:55, quoth Graeme Foot: > Are you interested in a patch that can read the SII information for a slave from > disk (if the slave has SII problems)? > > It can look up the SII "firmware" using the hotplug/udev framework (original > patch from Jesper Smith) or directly from a given directory via a > couple of > defines (my changes). It's an interesting idea, certainly. It's probably not something I'd make use of myself (all the slaves I'm using have good SII data) but I know there are slaves out there where the vendor has forgotten to program the EEPROM fully. The naming convention bothers me, though; I would expect the SII data needs to differ between different revisions of the slave as well (it certainly does for my slaves). Another problem is that without real SII data on the slaves themselves, they can't hold unique aliases, which is something else that I consider mandatory on my networks, at least. So I'm inclined to think that the "correct" reaction is to reprogram such slaves with their correct SII rather than trying to patch it at runtime. Although at least part of the SII must be working, otherwise you wouldn't be able to get the vendor/product ids (unless you're using an ENI file like TwinCAT, but that's a massive departure from the Etherlab model). I'm not opposed to including it anyway (if for no other reason than keeping handy patches in one place makes them less likely to get lost in the mists of time) but I'm curious what your motivating cases were?
2635-graemef-load_SII_from_file.patch
Description: 2635-graemef-load_SII_from_file.patch
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
