thankyou! On Friday, 1 July 2016 17:03:54 UTC+2, Schooner wrote: > > Hi > > I won't bother repeating what Charles and Michael already said, > usleep, read, write etc, all userspace. > > Attached is a conversion of your comp to a userspace format. > comp quite happily builds userspace components from C. > > It builds, but obviously I cannot test it. > > The initial usleep in the loop may not be required, it can be dispensed > with or adjusted as required > > regards > > > On 01/07/16 15:27, 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] <javascript:>. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > > >
-- 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.
