[Xenomai-help] CAN problem continued

[Xenomai-help] CAN problem continued

[roland Tollenaar]

Hi,

FYI

With enlarged ring buffer the overflow still takes place.

I have still not figured out why the can controller only runs in
passive mode from my application.

And i get these messages in dmessage.

Assertion failed! drivers/xenomai/can/rtcan_raw.c:rtcan_tx_push:171
dev->tx_socket == 0
(3) TX skb still in use
xeno_can: socket buffer overflow (fd=0), message discarded

The top message only once the bottom one the famous message that
happens all the time. I am now going to turn off the debug messages in
the config. I think there is something wrong with rt-can's error
logging behaviour.

Regards,

Roland.

Re: [Xenomai-help] CAN problem continued

[Sebastian Smolorz]

roland Tollenaar wrote:
> And i get these messages in dmessage.
>
> Assertion failed! drivers/xenomai/can/rtcan_raw.c:rtcan_tx_push:171
> dev->tx_socket == 0
> (3) TX skb still in use

Why are you trying to send loopback messages? Please strip your application 
down to the actual problematic situation. That means, remove all sending code 
and deactivate CONFIG_XENO_DRIVERS_CAN_LOOPBACK. We don't need it here. 
Please ensure that you open only one socket and bind it once. Start a RT 
thread that does nothing else than receiving CAN messages with a blocking 
call inside a while(1)-loop.

--
Sebastian

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

Hi

On 3/6/07, Sebastian Smolorz <ssm@domain.hid> wrote:
> roland Tollenaar wrote:
> > And i get these messages in dmessage.
> >
> > Assertion failed! drivers/xenomai/can/rtcan_raw.c:rtcan_tx_push:171
> > dev->tx_socket == 0
> > (3) TX skb still in use
>
> Why are you trying to send loopback messages?
I'm not. Of that I am certain.

Please strip your application
> down to the actual problematic situation. That means, remove all sending code
> and deactivate CONFIG_XENO_DRIVERS_CAN_LOOPBACK.
It takes 2 hours to rebuild the kernel and all the modules. I hope
this is not a kernel setting. loopback and listenonly capability is
set in the kernel but I am not using it at the moment. But it is
usefull for testing and it should not be a problem if not turned on?
It is NOT turned on.

> We don't need it here.
> Please ensure that you open only one socket and bind it once.
I have ensured. I am 100000% certain that it is only called once. I
have not touched rtcanrecv either. The only possibility is that if I
start the application multimple times that the old binds do not get
undone. What must I do to ensure that they are? How can I check for
this?

Start a RT
> thread that does nothing else than receiving CAN messages with a blocking
> call inside a while(1)-loop.
I cannot use blocking mode unless I cahnge the design intent of my
program. In that case I will run recv in blocking mode, write the
messages to a buffer of my own and perform my read on my own buffer. I
suggested doing this from the start but Wolfgang made me aware of the
DONTWAIT flag. If I have to resort to the other method it will be
because there is something wrong with rtcan recv functionality in non
blocking mode.

I have now recompiled the kernel + modules with larger buffer AND no
debug messaging (XENO_CAN_DEBUG something or other disabled). I have
reduced the output of the node to give so few messages that the buffer
overflow does not occurr anymore.

I am STILL getting fluctuations in period time when I turn the encoder
shaft. A little bit better than it used to be but not something I
would call real-time.

There is nothing else left but to go to blocking mode I am calling
bind only once, I have no messages coming onto dmesg anymore, I have a
large ring-buffer etc etc.

The flipping can controller is still starting up in passive mode and I
don;t know why.

Will let you know what happens in blocking mode.

Regards,

Roland



>
> --
> Sebastian
>

Re: [Xenomai-help] CAN problem continued

[Gilles Chanteperdrix]

roland Tollenaar wrote:
> It takes 2 hours to rebuild the kernel and all the modules.

Note that linux 2.6 is not like linux 2.4, you do not have to run make
clean before running make. So rebuilding after having modified one
option take just a few seconds. If you want to decrease the total kernel
build time, make a configuration where you disable everything that you
do not need. Yes, the configuration will take you some time, but you
will then save time at every compilation.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] CAN problem continued

[Sebastian Smolorz]

roland Tollenaar wrote:
> Hi
>
> On 3/6/07, Sebastian Smolorz <ssm@domain.hid> wrote:
> > roland Tollenaar wrote:
> > > And i get these messages in dmessage.
> > >
> > > Assertion failed! drivers/xenomai/can/rtcan_raw.c:rtcan_tx_push:171
> > > dev->tx_socket == 0
> > > (3) TX skb still in use
> >
> > Why are you trying to send loopback messages?
>
> I'm not. Of that I am certain.

The above kernel message states it clearly. Something on your computer is 
trying to send loopback messages. The above message can *only* appear if 
loopback is activated. So please investigate this issue and switch it off.

>
> Please strip your application
>
> > down to the actual problematic situation. That means, remove all sending
> > code and deactivate CONFIG_XENO_DRIVERS_CAN_LOOPBACK.
>
> It takes 2 hours to rebuild the kernel and all the modules.

2 hours?? Why?

> I hope 
> this is not a kernel setting. loopback and listenonly capability is
> set in the kernel but I am not using it at the moment. But it is
> usefull for testing and it should not be a problem if not turned on?

So far you are right.

> It is NOT turned on.

See above. I'm not convinced.

>
> > We don't need it here.
> > Please ensure that you open only one socket and bind it once.
>
> I have ensured. I am 100000% certain that it is only called once. I
> have not touched rtcanrecv either.

Then please do me a favour and only start rtcanrecv when your CAN node is 
sending. rtcanrecv is known to work. There should not be a socket buffer 
overflow.

> The only possibility is that if I 
> start the application multimple times that the old binds do not get
> undone. What must I do to ensure that they are? How can I check for
> this?

cat /proc/xenomai/rtdm/open_fildes
shows you all open descriptors. If there are some of then although your 
application is not running then do
echo 0 > /proc/xenomai/rtdm/open_fildes
for closing FD 0,
echo 1 > /proc/xenomai/rtdm/open_fildes
for closing FD 1, etc.

>
> Start a RT
>
> > thread that does nothing else than receiving CAN messages with a blocking
> > call inside a while(1)-loop.
>
> I cannot use blocking mode unless I cahnge the design intent of my
> program. In that case I will run recv in blocking mode, write the
> messages to a buffer of my own and perform my read on my own buffer. I
> suggested doing this from the start but Wolfgang made me aware of the
> DONTWAIT flag. If I have to resort to the other method it will be
> because there is something wrong with rtcan recv functionality in non
> blocking mode.

I suggested blocking mode only for testing purpose. I don't say that you can't 
use DONTWAIT. But if you want to find your bug your application should be as 
simple as possible.

>
> I have now recompiled the kernel + modules with larger buffer AND no
> debug messaging (XENO_CAN_DEBUG something or other disabled). I have
> reduced the output of the node to give so few messages that the buffer
> overflow does not occurr anymore.

As I said in a previous mail, disabling the DEBUG option does not make the 
overflows disappear, only their reporting. If your really want to solve your 
issue then you should activate it again.

>
> I am STILL getting fluctuations in period time when I turn the encoder
> shaft. A little bit better than it used to be but not something I
> would call real-time.

Probably because the overflows still take place but are not reported any more.

> The flipping can controller is still starting up in passive mode and I
> don;t know why.

How do you get this information?

-- 
Sebastian

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

Hi
 > > >
> > > > Assertion failed! drivers/xenomai/can/rtcan_raw.c:rtcan_tx_push:171
> > > > dev->tx_socket == 0
> > > > (3) TX skb still in use
> > >
> > > Why are you trying to send loopback messages?
> >
> > I'm not. Of that I am certain.
>
> The above kernel message states it clearly. Something on your computer is
> trying to send loopback messages. The above message can *only* appear if
> loopback is activated. So please investigate this issue and switch it off.
The place i look is in proc/rtcan/rtcan2/info. The mode is empty.
Always. I don;t set the mode in the application and on running
rtcanrecv I don't specify loopback.

What else can I do to make certain there is no listen_only mode on?

> > this is not a kernel setting. loopback and listenonly capability is
> > set in the kernel but I am not using it at the moment. But it is
> > usefull for testing and it should not be a problem if not turned on?
>
> So far you are right.
>
> See above. I'm not convinced.
If its any consolation I have not seen that message for a while. But
of course I have debug messages turned off in the kernel config now.


> > > Please ensure that you open only one socket and bind it once.
> >
> > I have ensured. I am 100000% certain that it is only called once. I
> > have not touched rtcanrecv either.
I think the messag overflowing is over now with the larger buffer and
the reduced baudrate. I have discovered that the 1ms was not 1ms when
the baudrate was at 1MB/s so that could have been the major cause for
the overflowing.

>
> Then please do me a favour and only start rtcanrecv when your CAN node is
> sending. rtcanrecv is known to work. There should not be a socket buffer
> overflow.
This can be confirmed.

>
> > The only possibility is that if I
> > start the application multimple times that the old binds do not get
> > undone. What must I do to ensure that they are? How can I check for
> > this?
>
> cat /proc/xenomai/rtdm/open_fildes
> shows you all open descriptors. If there are some of then although your
> application is not running then do
> echo 0 > /proc/xenomai/rtdm/open_fildes
> for closing FD 0,
> echo 1 > /proc/xenomai/rtdm/open_fildes
> for closing FD 1, etc.
Have checked. My application neatly alsways has 1 entry there and when
stopped the entry neatly dissapears. I only have a single bind.
But the message overflowing is over.


>
>
> I suggested blocking mode only for testing purpose. I don't say that you can't
> use DONTWAIT. But if you want to find your bug your application should be as
> simple as possible.
I have done this now. I have a thrid rt task called task3 which is
also set to run periodically only I have placed the blocking recv
function in there. This function puts all messages into a buffer of my
own which I read with a light read function from the 1ms task. See
later


> As I said in a previous mail, disabling the DEBUG option does not make the
> overflows disappear, only their reporting. If your really want to solve your
> issue then you should activate it again.
Ok. I can activate it again but before I deactivated it, the overflow
problem was over. See above.


>
> Probably because the overflows still take place but are not reported any more.
No. Certain about this. I will reconfirm becaause I have saved the
other kernel and modules so I can easily reload them. But I just
wanted to be sure that the messages were not the cause of the
fluctuations.


> > The flipping can controller is still starting up in passive mode and I
> > don;t know why.
>
> How do you get this information?
cat/proc/rtcan/rtcan2/info.

Quickly reverting to current state of affairs. I now do use the
blocking call and I have the same behaviour. It is impossible that I
have overflowing buffers now, yet when I turn the encoder shaft the
period times of task 1 and task2 fluctuate. task 3 is violating its
task time all the time because obviously it is stuck in the loop in
which I am continuously calling the blocking receive function.


There is no obvious process that is taking up a lot of CPU time, I can
see that there is system activity when I rotate the encoder shaft. I
have no idea how this is possible.

Maybe the violating task 3 is generating messages (which cannot be
seen because dmesg remains quiet and I have not disabled general rt
xenomai messages) but if that is the case why only when I let my node
send messages when I am rotating the shaft?

Are there any CAN errors that I can check for that might be causing
this? The idea that you had yesterday regarding the acknowledge? I
have run out of ideas, hope you have some.

I will turn on the debug messaging again since that clearly was not the problem.

Regards,

Roland



>
> --
> Sebastian
>

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

Slight correction. I AM getting CAN errors at the moment
 000000088. I believe this is bus error and protocol error.

Not sure why, termination seems right and the PDO messages are coming
across perfectly.

But perhaps this will give you some ideas?

Roland

On 3/6/07, roland Tollenaar <rolandtollenaar@domain.hid> wrote:
> Hi
>  > > >
> > > > > Assertion failed! drivers/xenomai/can/rtcan_raw.c:rtcan_tx_push:171
> > > > > dev->tx_socket == 0
> > > > > (3) TX skb still in use
> > > >
> > > > Why are you trying to send loopback messages?
> > >
> > > I'm not. Of that I am certain.
> >
> > The above kernel message states it clearly. Something on your computer is
> > trying to send loopback messages. The above message can *only* appear if
> > loopback is activated. So please investigate this issue and switch it off.
> The place i look is in proc/rtcan/rtcan2/info. The mode is empty.
> Always. I don;t set the mode in the application and on running
> rtcanrecv I don't specify loopback.
>
> What else can I do to make certain there is no listen_only mode on?
>
> > > this is not a kernel setting. loopback and listenonly capability is
> > > set in the kernel but I am not using it at the moment. But it is
> > > usefull for testing and it should not be a problem if not turned on?
> >
> > So far you are right.
> >
> > See above. I'm not convinced.
> If its any consolation I have not seen that message for a while. But
> of course I have debug messages turned off in the kernel config now.
>
>
> > > > Please ensure that you open only one socket and bind it once.
> > >
> > > I have ensured. I am 100000% certain that it is only called once. I
> > > have not touched rtcanrecv either.
> I think the messag overflowing is over now with the larger buffer and
> the reduced baudrate. I have discovered that the 1ms was not 1ms when
> the baudrate was at 1MB/s so that could have been the major cause for
> the overflowing.
>
> >
> > Then please do me a favour and only start rtcanrecv when your CAN node is
> > sending. rtcanrecv is known to work. There should not be a socket buffer
> > overflow.
> This can be confirmed.
>
> >
> > > The only possibility is that if I
> > > start the application multimple times that the old binds do not get
> > > undone. What must I do to ensure that they are? How can I check for
> > > this?
> >
> > cat /proc/xenomai/rtdm/open_fildes
> > shows you all open descriptors. If there are some of then although your
> > application is not running then do
> > echo 0 > /proc/xenomai/rtdm/open_fildes
> > for closing FD 0,
> > echo 1 > /proc/xenomai/rtdm/open_fildes
> > for closing FD 1, etc.
> Have checked. My application neatly alsways has 1 entry there and when
> stopped the entry neatly dissapears. I only have a single bind.
> But the message overflowing is over.
>
>
> >
> >
> > I suggested blocking mode only for testing purpose. I don't say that you can't
> > use DONTWAIT. But if you want to find your bug your application should be as
> > simple as possible.
> I have done this now. I have a thrid rt task called task3 which is
> also set to run periodically only I have placed the blocking recv
> function in there. This function puts all messages into a buffer of my
> own which I read with a light read function from the 1ms task. See
> later
>
>
> > As I said in a previous mail, disabling the DEBUG option does not make the
> > overflows disappear, only their reporting. If your really want to solve your
> > issue then you should activate it again.
> Ok. I can activate it again but before I deactivated it, the overflow
> problem was over. See above.
>
>
> >
> > Probably because the overflows still take place but are not reported any more.
> No. Certain about this. I will reconfirm becaause I have saved the
> other kernel and modules so I can easily reload them. But I just
> wanted to be sure that the messages were not the cause of the
> fluctuations.
>
>
> > > The flipping can controller is still starting up in passive mode and I
> > > don;t know why.
> >
> > How do you get this information?
> cat/proc/rtcan/rtcan2/info.
>
> Quickly reverting to current state of affairs. I now do use the
> blocking call and I have the same behaviour. It is impossible that I
> have overflowing buffers now, yet when I turn the encoder shaft the
> period times of task 1 and task2 fluctuate. task 3 is violating its
> task time all the time because obviously it is stuck in the loop in
> which I am continuously calling the blocking receive function.
>
>
> There is no obvious process that is taking up a lot of CPU time, I can
> see that there is system activity when I rotate the encoder shaft. I
> have no idea how this is possible.
>
> Maybe the violating task 3 is generating messages (which cannot be
> seen because dmesg remains quiet and I have not disabled general rt
> xenomai messages) but if that is the case why only when I let my node
> send messages when I am rotating the shaft?
>
> Are there any CAN errors that I can check for that might be causing
> this? The idea that you had yesterday regarding the acknowledge? I
> have run out of ideas, hope you have some.
>
> I will turn on the debug messaging again since that clearly was not the problem.
>
> Regards,
>
> Roland
>
>
>
> >
> > --
> > Sebastian
> >
>

Re: [Xenomai-help] CAN problem continued

[Sebastian Smolorz]

roland Tollenaar wrote:
> Hi
>
> > > > > Assertion failed! drivers/xenomai/can/rtcan_raw.c:rtcan_tx_push:171
> > > > > dev->tx_socket == 0
> > > > > (3) TX skb still in use
> > > >
> > > > Why are you trying to send loopback messages?
> > >
> > > I'm not. Of that I am certain.
> >
> > The above kernel message states it clearly. Something on your computer is
> > trying to send loopback messages. The above message can *only* appear if
> > loopback is activated. So please investigate this issue and switch it
> > off.
>
> The place i look is in proc/rtcan/rtcan2/info.

Why do you have so many CAN interfaces? What about rtcan0 and rtcan1? Does 
your CAN hardware have several CAN ports?

> The mode is empty. 
> Always. I don;t set the mode in the application and on running
> rtcanrecv I don't specify loopback.
>
> What else can I do to make certain there is no listen_only mode on?

You could explicitely call SIOCSCANCTRLMODE with 0.

>
> > > this is not a kernel setting. loopback and listenonly capability is
> > > set in the kernel but I am not using it at the moment. But it is
> > > usefull for testing and it should not be a problem if not turned on?
> >
> > So far you are right.
> >
> > See above. I'm not convinced.
>
> If its any consolation I have not seen that message for a while. But
> of course I have debug messages turned off in the kernel config now.

Without CONFIG_XENO_DRIVERS_CAN_DEBUG this message will never pop up.

> Slight correction. I AM getting CAN errors at the moment
> 000000088. I believe this is bus error and protocol error.

If this is the can_id field what do the data fields say?

--
Sebastian

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

> > The mode is empty.
> > Always. I don;t set the mode in the application and on running
> > rtcanrecv I don't specify loopback.
> >
> > What else can I do to make certain there is no listen_only mode on?
>
> You could explicitely call SIOCSCANCTRLMODE with 0.
Am now doing so. No difference.

>
> >
> > > > this is not a kernel setting. loopback and listenonly capability is
> > > > set in the kernel but I am not using it at the moment. But it is
> > > > usefull for testing and it should not be a problem if not turned on?
> > >
> > > So far you are right.
> > >
> > > See above. I'm not convinced.
> >
> > If its any consolation I have not seen that message for a while. But
> > of course I have debug messages turned off in the kernel config now.
>
> Without CONFIG_XENO_DRIVERS_CAN_DEBUG this message will never pop up.
>
> > Slight correction. I AM getting CAN errors at the moment
> > 000000088. I believe this is bus error and protocol error.
>
> If this is the can_id field what do the data fields say?
00 00 80 19 00 00 00 00

But once again, the node is sending.


>
> --
> Sebastian
>

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

Last sentence may be a bit ambiguous. I mean the node is sending
proper readings despite the CAN error.

May I me having problems with the BEI because of this error?

from the thread with Stephane I understand that this BEI cannot be switched off?

Regards,

Roland


On 3/6/07, roland Tollenaar <rolandtollenaar@domain.hid> wrote:
> > > The mode is empty.
> > > Always. I don;t set the mode in the application and on running
> > > rtcanrecv I don't specify loopback.
> > >
> > > What else can I do to make certain there is no listen_only mode on?
> >
> > You could explicitely call SIOCSCANCTRLMODE with 0.
> Am now doing so. No difference.
>
> >
> > >
> > > > > this is not a kernel setting. loopback and listenonly capability is
> > > > > set in the kernel but I am not using it at the moment. But it is
> > > > > usefull for testing and it should not be a problem if not turned on?
> > > >
> > > > So far you are right.
> > > >
> > > > See above. I'm not convinced.
> > >
> > > If its any consolation I have not seen that message for a while. But
> > > of course I have debug messages turned off in the kernel config now.
> >
> > Without CONFIG_XENO_DRIVERS_CAN_DEBUG this message will never pop up.
> >
> > > Slight correction. I AM getting CAN errors at the moment
> > > 000000088. I believe this is bus error and protocol error.
> >
> > If this is the can_id field what do the data fields say?
> 00 00 80 19 00 00 00 00
>
> But once again, the node is sending.
>
>
> >
> > --
> > Sebastian
> >
>

Re: [Xenomai-help] CAN problem continued

[Sebastian Smolorz]

roland Tollenaar wrote:
> > > Slight correction. I AM getting CAN errors at the moment
> > > 000000088. I believe this is bus error and protocol error.
> >
> > If this is the can_id field what do the data fields say?
>
> 00 00 80 19 00 00 00 00
>
> But once again, the node is sending.

It really, really seems that you are sending a message via your CAN interface. 
The 0x80 states that you got an error during transmission(!), the 0x19 says 
that this error is due to not being ack'ed. So this is strange. Once again: 
Please don't execute your program but execute rtcanrecv and see what happens.

Also post your insmod line.

What are the contents of /proc/rtcan?

> Last sentence may be a bit ambiguous. I mean the node is sending
> proper readings despite the CAN error.

Does that mean that you are receiving correct CAN frames sent from the node 
i.e. you can verify the correct contents?

> May I me having problems with the BEI because of this error?

You should not get this error when you don't send anything.

-- 
Sebastian

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

Hi

> > > If this is the can_id field what do the data fields say?
> >
> > 00 00 80 19 00 00 00 00
> >
> > But once again, the node is sending.
>
> It really, really seems that you are sending a message via your CAN interface.
you mean from my application?  Certainly not. If this were the case I
presume it would appear on rtcanrecv (when I run that it shows also
whatever my application is sending and if I run it at the same time as
my application then it only displays what is coming in from the node).

> The 0x80 states that you got an error during transmission(!),
Do these errors stay resident? I have to send in the beginning to get
the node into a mode where it will transmit PDO's it does not do so
otherwise.

 the 0x19 says
> that this error is due to not being ack'ed. So this is strange. Once again:
> Please don't execute your program but execute rtcanrecv and see what happens.
There seems to be no problem there. I also used the switch -e CAN_ERR_BUSERROR
but it only returns the PDO messages from the node. My applicaiotn
also returns them only it also sees the bus error??? Why is my
application seeing the error and rtcanrecv not?

I do know that if I look at the error count in /proc/rtcan/rtcan2/info
that it increases a bit after every start of my application by while
my application is running the count remains constant. Oops I have just
noticed that the stream I am putting out from my application only
results from startup, so I may now safely say that during running
there are no BUSERRORS.

>
> Also post your insmod line.

modprobe xeno_can_peak_dng type=epp io=0x378 irq=7


>
> What are the contents of /proc/rtcan?
rtcan0 rtcan1 and rtcan2 The first 2 are from the virtual can device.

>
> > Last sentence may be a bit ambiguous. I mean the node is sending
> > proper readings despite the CAN error.
>
> Does that mean that you are receiving correct CAN frames sent from the node
> i.e. you can verify the correct contents?
Yes. They are correct.


>
> > May I me having problems with the BEI because of this error?
>
> You should not get this error when you don't send anything.
Well that mystery is solved. Sorry for the confusion. I do have errors
when I send messages (but the messages are arriving at the node
because it responds PERFECTLY) no amount of playing with the
termination improves matters during startup I always get the buserror
when I am sending. Maybe it taks a whle for the bus to come up and in
that little period there is an error. i do know that one write cycle
is always run twice before the node responds. But this is very
consistent behaviour.


But the real-time behaviour continues to e disruppted when the node is rotated.

Does any of the above info help?

Roland

>
> --
> Sebastian
>

Re: [Xenomai-help] CAN problem continued

[Sebastian Smolorz]

Hi,

now the picture becomes clearer. :)

roland Tollenaar wrote:
> Hi
>
> > > > If this is the can_id field what do the data fields say?
> > >
> > > 00 00 80 19 00 00 00 00
> > >
> > > But once again, the node is sending.
> >
> > It really, really seems that you are sending a message via your CAN
> > interface.
>
> you mean from my application?  Certainly not.

Yes, you do, and luckily you admit it later. ;)

> If this were the case I 
> presume it would appear on rtcanrecv (when I run that it shows also
> whatever my application is sending and if I run it at the same time as
> my application then it only displays what is coming in from the node).
>
> > The 0x80 states that you got an error during transmission(!),
>
> Do these errors stay resident? I have to send in the beginning to get
> the node into a mode where it will transmit PDO's it does not do so
> otherwise.

Ok, that was an important missing piece of information.

> > What are the contents of /proc/rtcan?
>
> rtcan0 rtcan1 and rtcan2 The first 2 are from the virtual can device.

Only to be absolutely sure: Please don't load the virtual device for now.

> > > May I me having problems with the BEI because of this error?
> >
> > You should not get this error when you don't send anything.
>
> Well that mystery is solved. Sorry for the confusion. I do have errors
> when I send messages (but the messages are arriving at the node
> because it responds PERFECTLY) no amount of playing with the
> termination improves matters during startup I always get the buserror
> when I am sending. Maybe it taks a whle for the bus to come up and in
> that little period there is an error. i do know that one write cycle
> is always run twice before the node responds. But this is very
> consistent behaviour.

OK, this could be an explanation for the error frames. Good news that they 
appear only during setting up the node.

>
>
> But the real-time behaviour continues to e disruppted when the node is
> rotated.

Could you do the following: Fire up rtcanrecv and send out the setup message 
to the node with rtcansend. Don't start your application during the whole 
time and watch what happens.

-- 
Sebastian

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

Hi Sebastian,

> > rtcan0 rtcan1 and rtcan2 The first 2 are from the virtual can device.
>
> Only to be absolutely sure: Please don't load the virtual device for now.
Hell, I think its baked into my kernel so I will have to recompile.
I'll explain some other time why this is such a big issue in my case.

> > Well that mystery is solved. Sorry for the confusion. I do have errors
> > when I send messages (but the messages are arriving at the node
> > because it responds PERFECTLY) no amount of playing with the
> > termination improves matters during startup I always get the buserror
> > when I am sending. Maybe it taks a whle for the bus to come up and in
> > that little period there is an error. i do know that one write cycle
> > is always run twice before the node responds. But this is very
> > consistent behaviour.
>
> OK, this could be an explanation for the error frames. Good news that they

> > But the real-time behaviour continues to e disruppted when the node is
> > rotated.
>
> Could you do the following: Fire up rtcanrecv and send out the setup message
> to the node with rtcansend. Don't start your application during the whole
> time and watch what happens.
:( Its not one message, its about 6 can rtcanrecv run scripts?

Will get onto it now.

Roland



>
> --
> Sebastian
>

Re: [Xenomai-help] CAN problem continued

[Sebastian Smolorz]

roland Tollenaar wrote:
> > Could you do the following: Fire up rtcanrecv and send out the setup
> > message to the node with rtcansend. Don't start your application during
> > the whole time and watch what happens.
> >
> :( Its not one message, its about 6 can rtcanrecv run scripts?

I don't understand exactly. Could you elaborate on what is necessary to get 
the node up?

-- 
Sebastian

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

Hi

On 3/6/07, Sebastian Smolorz <ssm@domain.hid> wrote:
> roland Tollenaar wrote:
> > > Could you do the following: Fire up rtcanrecv and send out the setup
> > > message to the node with rtcansend. Don't start your application during
> > > the whole time and watch what happens.
> > >
> > :( Its not one message, its about 6 can rtcanrecv run scripts?

Ok done with rtcansend and rtcanrecv. Perfect behavior i.e exactly the
same behaviour as I get when i run my applicaiton. Obviously there is
no indication as to the real-time disruptiveness because I can only
see that from my application. Which is not running.

>
> I don't understand exactly. Could you elaborate on what is necessary to get
> the node up?

pre-operational state,  then 4 SDO messages to set it into continuous
sending @ 1ms.

I have also turned off bits of my code here andd there to ensure that
it is not my processing that can be doingthis. But there is no
processing, there is only reading.

Regards,

Roland





>
> --
> Sebastian
>

Re: [Xenomai-help] CAN problem continued

[Sebastian Smolorz]

roland Tollenaar wrote:
> Hi
>
> On 3/6/07, Sebastian Smolorz <ssm@domain.hid> wrote:
> > roland Tollenaar wrote:
> > > > Could you do the following: Fire up rtcanrecv and send out the setup
> > > > message to the node with rtcansend. Don't start your application
> > > > during the whole time and watch what happens.
> > > >
> > > :( Its not one message, its about 6 can rtcanrecv run scripts?
>
> Ok done with rtcansend and rtcanrecv. Perfect behavior i.e exactly the
> same behaviour as I get when i run my applicaiton. Obviously there is
> no indication as to the real-time disruptiveness because I can only
> see that from my application. Which is not running.

So let me summarise:
- With rtcansend/rtcanrecv and without your application the communication with 
the node is perfect (overflows?)
- With your application running you state that the real-time behaviour of the 
system is bad. How do you detect this?

-- 
Sebastian

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

Hi

> So let me summarise:
> - With rtcansend/rtcanrecv and without your application the communication with
> the node is perfect (overflows?)
No more overflows. Nowhere. Have the debug messaging back on,
everything is quiet. Especially witht he blocking mode construction
overflowing should (and is) be impossible.

> - With your application running you state that the real-time behaviour of the
> system is bad. How do you detect this?
I measure the period times. Here is the snippet


void cyclicloop(void *arg)
{
	RTIME now, previous;

	/*
	 * Arguments: &task (NULL=self),
	 *            start time,
	 *            period (here: 1 ms=1000000)
	 */
	rt_task_set_periodic(NULL, TM_NOW, TASK_PERIOD);
	previous = rt_timer_read();

	while (!TasksHalt) {
		rt_task_wait_period(NULL);
		now = rt_timer_read();
		//Read inputs here
		atm60_configure(can_device);	
		//Set analog output here
		//Do controller calculations here
		

		
		
		//Get time period
		double TimeVarTemp=(double)(now - previous);
		Task1Period=TimeVarTemp/ 1000000;
		//printf("Time since last turn: %f ms\n",Task1Period);
		previous = now;

		/*
		 * NOTE: printf may have unexpected impact on the timing of
		 *       your program. It is used here in the critical loop
		 *       only for demonstration purposes.
		*/
		
	}
}//cyclicloop

void catch_signal(int sig)
{
}


void task1(void)
{
	signal(SIGTERM, catch_signal);
	signal(SIGINT, catch_signal);

	// Avoids memory swapping for this program
	//Not necessary here because QTThread must take care of this.Only
needed once inthe entire program (multithread) Jan Kizka email
	//Apparently IS necessary application otherwise seems to crash.
placed in main()
	//mlockall(MCL_CURRENT|MCL_FUTURE);

	//
	 // Arguments: &task,
	 //            name,  [Name must be unique for each task]
	 //            stack size (0=default),
	 //            priority,
	 //            mode (FPU, start suspended, ...)
	 //
	rt_task_create(&rt_task_1, "rt_task1", 0, 99, 0);

	//
	 // Arguments: &task,
	 //            task function,
	 //            function argument
	 //
	rt_task_start(&rt_task_1, &cyclicloop, NULL);

	//if(!Task1Halt)
	//	pause();

	//rt_task_delete(&rt_task_1);

}

its actually straight from the trivial task example. The TaskPeriod1
is a global variable which is displayed in another thread every 0.5
seconds.

Roland


>
> --
> Sebastian
>

Re: [Xenomai-help] CAN problem continued

[Sebastian Smolorz]

roland Tollenaar wrote:

>
> > - With your application running you state that the real-time behaviour of
> > the system is bad. How do you detect this?
>
> I measure the period times. Here is the snippet
>
>
> void cyclicloop(void *arg)
> {
> 	RTIME now, previous;
>
> 	/*
> 	 * Arguments: &task (NULL=self),
> 	 *            start time,
> 	 *            period (here: 1 ms=1000000)
> 	 */
> 	rt_task_set_periodic(NULL, TM_NOW, TASK_PERIOD);
> 	previous = rt_timer_read();
>
> 	while (!TasksHalt) {
> 		rt_task_wait_period(NULL);
> 		now = rt_timer_read();
> 		//Read inputs here
> 		atm60_configure(can_device);

What does this function do?

> 		//Set analog output here
> 		//Do controller calculations here
>
>
>
>
> 		//Get time period
> 		double TimeVarTemp=(double)(now - previous);
> 		Task1Period=TimeVarTemp/ 1000000;
> 		//printf("Time since last turn: %f ms\n",Task1Period);
> 		previous = now;
>
> 		/*
> 		 * NOTE: printf may have unexpected impact on the timing of
> 		 *       your program. It is used here in the critical loop
> 		 *       only for demonstration purposes.
> 		*/
>
> 	}
> }//cyclicloop

-- 
Sebastian

Re: [Xenomai-help] CAN problem continued

[roland Tollenaar]

> > void cyclicloop(void *arg)
> > {
> >       RTIME now, previous;
> >
> >       /*
> >        * Arguments: &task (NULL=self),
> >        *            start time,
> >        *            period (here: 1 ms=1000000)
> >        */
> >       rt_task_set_periodic(NULL, TM_NOW, TASK_PERIOD);
> >       previous = rt_timer_read();
> >
> >       while (!TasksHalt) {
> >               rt_task_wait_period(NULL);
> >               now = rt_timer_read();
> >               //Read inputs here
> >               atm60_configure(can_device);
>
> What does this function do?
steps through the initialisation phase and then ends up just calling
the read function. I could have just as well replaced it with the read
function for the example here. can_device="rtcan2".

Roland


>
> >               //Set analog output here
> >               //Do controller calculations here
> >
> >
> >
> >
> >               //Get time period
> >               double TimeVarTemp=(double)(now - previous);
> >               Task1Period=TimeVarTemp/ 1000000;
> >               //printf("Time since last turn: %f ms\n",Task1Period);
> >               previous = now;
> >
> >               /*
> >                * NOTE: printf may have unexpected impact on the timing of
> >                *       your program. It is used here in the critical loop
> >                *       only for demonstration purposes.
> >               */
> >
> >       }
> > }//cyclicloop
>
> --
> Sebastian
>