CANLIB

We are currently using Orocos with CANOpen (PCAN PCI card). When I was installing the new OCL (thank you), I see an entry in ccmake for CANLIB, but nothing seems to be documented further. This made me curious, and I digged some more. In the websvn, I see that you have been doing this already! We'll be checking this out, but would you be willing to give me some additional pointers or hints to documents other than the cpp files?
Much appreciated!

Thanks, Theo.

CANLIB

On Sunday 22 February 2009 22:18:56 t [dot] j [dot] a [dot] devries [..] ... wrote:
> We are currently using Orocos with CANOpen (PCAN PCI card). When I was
> installing the new OCL (thank you), I see an entry in ccmake for CANLIB,
> but nothing seems to be documented further. This made me curious, and I
> digged some more. In the websvn, I see that you have been doing this
> already! We'll be checking this out, but would you be willing to give me
> some additional pointers or hints to documents other than the cpp files?
> Much appreciated!

This is actually dead CMake code... We only use libpcan.h in
PCANController.hpp.

We are planning in the very short term to fixup the CAN* classes in OCL.
Mainly, all the 'Open' parts (both name and functions, like nodeId() ) of the
CAN* classes will be removed, such that only the pure CAN protocol is
represented in C++. In addition, a SocketCANController (plain Linux) and
RTSockedCANController (Xenomai/RTDM) class will be added.

Peter

CANLIB

sspr wrote:

On Sunday 22 February 2009 22:18:56 t [dot] j [dot] a [dot] devries [..] ... wrote:
> We are currently using Orocos with CANOpen (PCAN PCI card). When I was
> installing the new OCL (thank you), I see an entry in ccmake for CANLIB,
> but nothing seems to be documented further. This made me curious, and I
> digged some more. In the websvn, I see that you have been doing this
> already! We'll be checking this out, but would you be willing to give me
> some additional pointers or hints to documents other than the cpp files?
> Much appreciated!

This is actually dead CMake code... We only use libpcan.h in
PCANController.hpp.

We are planning in the very short term to fixup the CAN* classes in OCL.
Mainly, all the 'Open' parts (both name and functions, like nodeId() ) of the
CAN* classes will be removed, such that only the pure CAN protocol is
represented in C++. In addition, a SocketCANController (plain Linux) and
RTSockedCANController (Xenomai/RTDM) class will be added.

Peter

Ok, thanks for the info. We'll be interested in the updated classes.

Cheers, Theo

CANLIB

Does someone has already tried to use CANOpen with Orocos? We plan to use CanFestival with a Peak Systems card in a new project. Since the driver is RTAI compatible [1, 2], I think there will be no major issue to put it in a real time Orocos component.<br>
<br>[1] <a href="http://www.canfestival.org/documentation/supported-platforms-and-can-devices">http://www.canfestival.org/documentation/supported-platforms-and-can-devices</a><br>[2] <a href="http://www.peak-system.com/fileadmin/media/linux/index.htm">http://www.peak-system.com/fileadmin/media/linux/index.htm</a><br>
<br>Philippe<br><br><div class="gmail_quote">2009/2/26 Peter Soetens <span dir="ltr">&lt;<a href="mailto:peter [dot] soetens [..] ...">peter [dot] soetens [..] ...</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sunday 22 February 2009 22:18:56 <a href="mailto:t [dot] j [dot] a [dot] devries [..] ...">t [dot] j [dot] a [dot] devries [..] ...</a> wrote:<br>
&gt; We are currently using Orocos with CANOpen (PCAN PCI card). When I was<br>
&gt; installing the new OCL (thank you), I see an entry in ccmake for CANLIB,<br>
&gt; but nothing seems to be documented further. This made me curious, and I<br>
&gt; digged some more. In the websvn, I see that you have been doing this<br>
&gt; already! We&#39;ll be checking this out, but would you be willing to give me<br>
&gt; some additional pointers or hints to documents other than the cpp files?<br>
&gt; Much appreciated!<br>
<br>
This is actually dead CMake code... We only use libpcan.h in<br>
PCANController.hpp.<br>
<br>
We are planning in the very short term to fixup the CAN* classes in OCL.<br>
Mainly, all the &#39;Open&#39; parts (both name and functions, like nodeId() ) of the<br>
CAN* classes will be removed, such that only the pure CAN protocol is<br>
represented in C++. In addition, a SocketCANController (plain Linux) and<br>
RTSockedCANController (Xenomai/RTDM) class will be added.<br>
<br>
Peter<br>
--<br>
Peter Soetens -- FMTC -- &lt;<a href="http://www.fmtc.be" target="_blank">http://www.fmtc.be</a>&gt;<br>
<font color="#888888">--<br>
Orocos-Users mailing list<br>
<a href="mailto:Orocos-Users [..] ...">Orocos-Users [..] ...</a><br>
<a href="http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users" target="_blank">http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users</a><br>
<br>
Disclaimer: <a href="http://www.kuleuven.be/cwis/email_disclaimer.htm" target="_blank">http://www.kuleuven.be/cwis/email_disclaimer.htm</a><br>
<br>
</font></blockquote></div><br>

CANLIB

On Thu, Feb 26, 2009 at 4:22 PM, Philippe Hamelin
<philippe [dot] hamelin [..] ...> wrote:
> Does someone has already tried to use CANOpen with Orocos? We plan to use
> CanFestival with a Peak Systems card in a new project. Since the driver is
> RTAI compatible [1, 2], I think there will be no major issue to put it in a
> real time Orocos component.
>
> [1]
> http://www.canfestival.org/documentation/supported-platforms-and-can-dev...
> [2] http://www.peak-system.com/fileadmin/media/linux/index.htm

We (FMTC) have done it in a bi-lateral project of which the source
code hasn't been released though. We were using the same card, but
were running CanFestival on Xenomai (using the driver that comes with
xenomai instead of the one provided by Peak), it took (quite) some
effort to get things working (see the CanFestival ML for details) but
it worked out fine in the end.
AFAIK (check on the CF mailinglist), the CanFestival RTAI path has
been revised at the same path and should be reasonably stable (at that
time :-).

Klaas