I ran with the python HAL for another 2 weeks and everything's been working fine. The jitter turned out to be a problem with the serial connection between the microcontroller and the radio link.
On Friday, 1 July 2016 16:27:14 UTC+2, matthew venn wrote: > > Thanks Charles. > I started off with a non realtime python program loaded using loadusr, but > it seemed too jittery to me. > I'll have another go and post back. > > Matt > > On Friday, 1 July 2016 15:56:32 UTC+2, Charles Steinkuehler wrote: >> >> On 7/1/2016 8:01 AM, matthew venn wrote: >> > Hello, >> > >> > I'm working on a bipod (polargraph) style drawing robot. I'm using >> machinekit on >> > beaglebone. >> > >> > I'm moving the pen up and down with a radio (xbee) controlled servo. >> I've >> > written a hal component in C that opens (non blocking) a serial port on >> the >> > beaglebone and then reads and writes to it. The component takes just >> over 25ms >> > to run. >> > This component is added to a slow thread (50ms). I don't get realtime >> error >> > messages or joint following errors. >> >> You should add something that takes that long to run to a >> non-real-time thread. Even in a slow RT thread, your code is running >> with real-time priority which keeps other parts of the system from >> getting CPU cycles. >> >> Just write a normal program that does what you need and use "loadusr" >> instead of "loadrt". You can even craft code in python for talking to >> slow things like serial ports. See the python temperature reading >> code (in the various 3D printer configs) for an example: >> >> >> https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps/hal_temp_bbb.py >> >> >> If you really want to use a real-time HAL component for this, you need >> to code the logic so each pass through the function happens quickly. >> That means keeping track of your current state in variables that >> survive across calls to your function, and when your function does >> run, you check to see if you can do the next step (like write the next >> byte or read a character). If so, you do that, otherwise you just >> exit. Also, you need to talk directly to the hardware (or via an >> existing HAL driver). Performing system calls (like reading or >> writing to a file descriptor) and doing things like usleep() in a RT >> function are very bad. The system calls will break all real-time >> guarantees for HAL, since the Linux kernel can do anything (like page >> a bunch of memory out to swap) once you give it control, and your >> usleep() is just burning CPU cycles at real-time priority. >> >> I strongly suggest you use a user-mode HAL component instead. The >> code you've got would be fine as a user-mode component. >> >> -- >> Charles Steinkuehler >> [email protected] >> > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
