Hi Mario,

thanks for the detailed report. I'll be waiting for the exact 
messages.
But until them some clarifications:

> So, what the problem was:
>
> 1) I made a new computer and a fresh install Ubuntu 6.06LTS, 
> +EMC2.0.5, +axis

I assume you used the debian packages. How do you run emc? (var1: from 
the menu, var2: open terminal, go to a dir, issue: scripts/emc) ?

> 2) The Geforce 6100 VGA was installed as vesa in xorg.conf
> 3) When I changed the VGA to GeForce 7300 GT, all problems/features
> remained exactly the same.
> 4) Meanwhile... I made 2 new setup configurations (canon.ini), all 
> went OK
> 5) I discovered a bug: when trying to move the slider of Feed 
> Override
> to even 105%, I got message "Unexpected realtime delays, check dmesg
> for...." Tried tkemc and axis - same results.

The unexpected realtime delay works like this for emc2.0.5:

I). it records 5 of the last runs of the motion controller
II). it looks if the current time to run the motion controller exceeds 
any previous run by more than 10%
III). if more than 10% is seen, it triggers that error.

So in your case the motion controller should run at exactly 1msec, and 
the difference which you showed (much more clearly in the logs you'll 
hopefully send us soon) of "0.957ms, 1ms, 1ms, 1ms, 1ms and last one 
1.053ms" is the explanation for the unexpected realtime delay. If you 
check the difference between 0.957ms and 1.053ms you'll see it's 
exactly 10%.

The 10% have been chosen quite arbitrarly, it could be that in your 
case it's only a bogus error message.
Does anything else noticeable happen? Motors failing? do you hear a 
certain bang in the sound from the motors?

> 6) dmesg said that there were numerous delays of about 
> (recalculated)
> 1 milisecond
> 7) I changed processor frequency up/down - the delay and bug 
> remained
> the same - 1 milisecond...
>
> 8) When changed the video driver to "nv" for magma core, deleted 
> many
> useless input devices in xorg.conf, the bug is much, much harder to
> cause. Two minutes playing with the slider and system loaded to 100%
> by other applications.
>
> I suspect that the bug *could* be caused by issuing too many feed
> override commands in short time.

If I made the above clear (not that sure I did), you'll understand 
it's not a bug. Merely a Safety feature, that tells you something took 
a bit longer to work than it should.


> Will try this... Chenge servo period to some long time...

I suspect that if you increase the servo base period, you won't notice 
the anomaly anymore (10% in 2msec is a lot more than in 1msec).
On the other hand, I'm not sure that's such a good idea. It all 
depends what else is failing (if anything).

Older versions of emc2 (before 2.0.4) had no idea how to tell if there 
was a "Unexpected realtime delay", so you would have just worked along 
without knowing any of this, and it probably would have worked OK.

Regards,
Alex Joni

>
> On 12/26/06, Alex Joni <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hello Mario,
>>
>> I still don't think I understand your  problem.
>> I've been reading through all your emails (at least  the ones I 
>> have), and it seems like one email at least got lost.
>> There is no email describing what the actual  problem is. Sure you 
>> talk about 1ms something.. but it's not clear at all what  the 
>> problem is.
>>
>> Regarding the 1msec, I see you have the  SERVO_PERIOD set to 
>> 1000000 nsec = 1msec
>> So any change you send to the motion controller  would happen at 
>> 1msec (including the feed override changes).
>>
>> Maybe try again (from the beginning, and with  assuming we know 
>> nothing) to explain what exactly the problem is, and what you  are 
>> doing to show it.
>>
>> Regards,
>> Alex
>>
>> PS: when you move the slider (either AXIS or tkemx,  or any other 
>> GUI), a NML message gets composed then sent to task (emctask), this 
>> one queues it, and when it's ok it send it to the motion 
>> controller, which sets  the new value by calling a TP specific 
>> function.
>> The other way (display of the current feed  override) happens by 
>> means of the status structure, and later on with a NML  status 
>> message.
>> There is _absolutely no way_ the moving of the  slider per se to 
>> cause the glitch (if that's what your problem is). What can be, 
>> and I am not ruling it out, is a problem when applying the new 
>> feed_override in  TP, maybe some accel which is too high, and 
>> causes motors to stall (if your  setting of 450 mm/s^2 is not 
>> appropriate). I also notice you have some BACKLASH  configure in 
>> there, might want to take that out during testing (to rule out 
>> every possible cause of problems).
>>
>> 


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to