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] <javascript:> > -- 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.
