I continue development of an existing project we have with MpDataRecorder logging to USB and have some questions. I’m testing it on X20CP0482 and 4PPC70_0702_21W.
USB - Is it really necessary with an example program with 200 lines like B&R “read_data.st” just to get a device handle to the USB driver for the recorder? This seems both overly complicated since it appears to list files as well, also something that, if nececcsary, should be included in the AsUsb library as an FB rather than editable example programs. What I’m looking for is if the OS on either of these platforms can built-in already handle this as input to the recorder by just specifying USB.IF4 or IF5 on the recorder? Insert stick. Read the status of IF4. Boom. Or - a minimal program/setting to just assign a drive handle?
Recorder - On CP0482 only, I seem to get ERR_MPLINK_IN_USE often after transferring and it is solved by a cold restart every time. I have included .enable false of both the recorder and MpDataRegPar in the exit routine.
Hi Jon,
I understand your concern. We want to provide the maximum flexibility for USB device. You can not only connect media device but also serial devices like barcode readers. You can also connect USB hubs that allow you to connect more devices. It is therefore necessary to identify the device clearly.
We use the neutral term file devices as an abstract layer which makes it very easy to switch from USB devices to a local flash card or even a network device.
There is an example for connecting USB file devices on GitHub.
I found what I was looking for:
Just set Config / File device / File device[n].path = “/bd0” and use .name as string reference to the recorder. There is no need to know anything more about the USB stick.
Edit: I corrected the second device being /bd16, not /bd1. (Though this may be a recollection from very early implementations of AsUsb).
This will only be valid if there is only ever 1 usb stick plugged in. The moment a second one is plugged in, the second one becomes /bd16. If the first one is unplugged. /bd0 is not valid anymore, and will get reassigned if the first is reinserted or a third is plugged in.
I’m running this on CP0482 with AS4.12. The first stick is /bd0 and the second /bd16 - just like the information in the provided earlier post. Also when removing and reinserting just one stick /bd0 is still used and works seamlessly after error ack.
When you only have 2 ports you can be confident that it will be on either /bd0 or /bd16. When you are using APC’s some of them have up to 7 USB ports.
But My point was more the following: /bd0 is the first one plugged in, not a specific port on the device. So if you have 2 devices plugged in and you want to write to a specific one it’s a little bit more complicated. As @stephan.stricker said, hubs will increase the available number of ports and you will have many more /bdXXX possibilities. If you have a APC with an internal USB port and MSD tech guard mounted in it, it will always be /bd0 if no other devices are plugged in at boot.
Also B&R has the 0TG1000.01 | B&R Industrial Automation which is shows up as a mass storage device and not a human interface device on the USB bus. Depending on how you have structured your code to use the AsUsb library, you might devlink to this as your /bd0 and it is not really useable as a MSD, if you don’t check device size or vendor Id before devlinking.
Also regarding your original post for this thread. Make sure your exit routine also includes a devunlink to undo your devlink to the USB drive. The read_data example doesn’t automatically unlink, and if have your transfer set to keep PVs, your file device links may have been broke with the transfer. It is best practice to devlink->file operations->devunlink and not just leave the devlink open. If you do make sure you include unlinking in your exit code.
