Hi Yegor and François,
Thanks for your replies. I've made some progress.
As per Yegor's suggestion I was able to use candump and cansend
succesfully, with
$ candump can0
running in the terminal I could see
can0 702 [1] 00
when I switched the device on, I understand that this means node 2 is
preoperational (702 = 700 (can specifier) + 2 (nodeid)).
I could also ask for the device name (following the instructions here:
http://www.canopensolutions.com/english/about_canopen/device_configuration_canopen.shtml
)
$ cansend can0 602#40.08.10.00.00.00.00.00
$ cansend can0 602#60.00.00.00.00.00.00.00
produced:
can0 602 [8] 40 08 10 00 00 00 00 00
can0 582 [8] 41 08 10 00 05 00 00 00
can0 602 [8] 60 00 00 00 00 00 00 00
can0 582 [8] 05 45 50 4F 53 32 00 00
in candump, in the second line the '05' means a 5 character name and in the
fourth line 45 = E, 50 = P, 4F = O, 53 = S, 32 = 2, spells EPOS2 in
ASCII... magic.
So the driver is clearly working.
When I configure CanFestival with
$ ./configure --can=peak_linux
and then try:
$ CANOpenShell load#libcanfestival_can_peak.so,0,1M,2,0
I still get: undefined symbol: LINUX_CAN_Open
However if I configure with SocketCAN:
$ ./configure --can=socket
as suggested by François, and then run:
$ CANOpenShell load#libcanfestival_can_socket.so,0,1M,2,0
Node_initialisation
Node_preOperational
and candump gives:
can0 702 [1] 00
for resetting the node. Whilst in CANOpenShell I typed:
rsdo#2,1008,00
To read the device name as I did before with cansend and the result was:
##################################
#### Read SDO ####
##################################
NodeId : 02
Index : 1008
SubIndex : 00
Result : 534f5045
Segmentation fault (core dumped)
and it threw me out of the CANOpenShell, candump gave:
can0 602 [8] 40 08 10 00 00 00 00 00
can0 582 [8] 41 08 10 00 05 00 00 00
can0 602 [8] 60 00 00 00 00 00 00 00
can0 582 [8] 05 45 50 4F 53 32 00 00
just as before. The value returned in 'Result' spells out SOPE so it's
partially right, is the segmentation fault something I should worry about?
If instead I send:
$ rsdo#2,1000,00
to read the device type I get Result: 20192 (which is correct 02 => servo
drive, 0192 => CiA 402 standard) and I don't get the segmentation fault and
I'm not thrown out of CANOpenShell. I've read several other objects in the
dictionary without yet being able to replicate the segmentation fault I get
with reading the device name, is it something to do with it needing more
than one COB to read?
The driver I use is the "official" one from peak systems own website (at
the bottom of this page):
http://www.peak-system.com/fileadmin/media/linux/index.htm
I don't really understand the relationship between SocketCAN and the Peak
driver I'm using, would one of you be able to explain it a bit to me? Is
SocketCAN another layer above the driver or is it an alternative driver, do
I not need to bother installing the Peak driver. I didn't install anything
extra for SocketCAN so is it already in the mainline kernel or was it
installed when I configured CanFestival for SocketCAN?
Also, I have a question about real time control. Am I best using a Xenomai
patched kernel which CanFestival seems to support or could I just as well
use a preempt_rt patched kernel such as the one maintained by Alessio
Bogani here: https://launchpad.net/~abogani/+archive/realtime
Other than the segmentation fault everything seems to be working correctly,
I'm going to work on actually making the motor move now. Thanks again for
the help.
Regards,
Derek
|