Back
[03:00:35] <rayh> I'm getting a compile error on trunk.
[03:01:12] <rayh> Anyone else seeing it. rs274ngc.hh
[03:01:58] <rayh> I believe that I tested the stuff I added to that file recently.
[03:02:21] <jepler> I think lerman also made a commit to that file. you may have a conflict now after updating.
[03:02:32] <jepler> If there's a "<<<<" in the file then that's what happened.
[03:03:45] <rayh> phrase not found
[03:05:01] <jepler> ok maybe you're right then
[03:05:12] <jepler> I jumped to the conclusion that this was the cause because the compile farm was OK
[03:05:45] <CIA-34> EMC: 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/rs274ngc.hh: apparently that usage is OK on older machines, but not on Hardy Heron's gcc
[03:05:48] <jepler> there, that should fix it
[03:05:49] <jepler> 'night
[03:06:02] <rayh> Ah. thanks guy.
[08:07:56] <pmbdk> probably no one here... :-) But here it goes anyway...
[08:08:29] <pmbdk> I understand that there is a shared mem i/f between the emctask and the rt motion stuff
[08:09:14] <pmbdk> this shared mem is basically a struct being updated once per servo loop
[08:09:47] <alex_joni> right
[08:10:04] <pmbdk> assuming that the trajectory planner spits out info to this buffer at the _same_ rate as the servo loop
[08:10:22] <pmbdk> wouldn't this be a problem?
[08:11:19] <pmbdk> just an example: servo loop rate is 1 ms
[08:11:31] <pmbdk> trajectory is 1 ms as well
[08:12:13] <alex_joni> there is a buffer though (inside RT)
[08:12:16] <pmbdk> since emctask si userspace prog this can not guarentee that it can put stuff in the struct in a timely manner
[08:12:24] <alex_joni> for motion stuff
[08:12:37] <pmbdk> yep, i know the buffer (some 2000), but during startup ?
[08:12:48] <pmbdk> or during end for that matter?
[08:12:50] <alex_joni> I don't follow
[08:13:02] <alex_joni> who's startup?
[08:13:12] <pmbdk> my bad, just rushing into it... :)
[08:13:15] <alex_joni> emc2? program?
[08:13:39] <pmbdk> ok, as I see it, we have emctask comm with motion using the shmem i/f
[08:13:46] <pmbdk> emc2
[08:14:08] <pmbdk> please correct me if im wrong... :)
[08:14:24] <pmbdk> emctask takes care of reading the g-code file
[08:14:34] <pmbdk> using the rs274 intepreter
[08:15:28] <pmbdk> emctasks also takes care of the trajectory computations; this can be for example at 1 ms intervals
[08:16:21] <pmbdk> emctask sends motion commands to the rt motion subsystem
[08:16:28] <pmbdk> through the shmem if
[08:16:33] <alex_joni> err.. no
[08:16:43] <alex_joni> emctask does no such thing as traj computations
[08:16:54] <pmbdk> ok, so i misunderstood something... :)
[08:16:56] <alex_joni> emctask calls the interpreter once per cycle
[08:17:05] <alex_joni> interpreter converts teh g-code to canonical commands
[08:17:11] <alex_joni> which go on a buffer
[08:17:23] <alex_joni> emctask takes stuff from that buffer and passes it to motion
[08:17:38] <pmbdk> isn't the interpreter part of emctask?
[08:17:47] <alex_joni> it gets linked together
[08:17:55] <alex_joni> but different logical parts
[08:18:23] <pmbdk> AH! So the the canonical commands goes to the motion prog?
[08:18:28] <alex_joni> right
[08:18:42] <alex_joni> so you get a command like: linear move to end location
[08:18:50] <alex_joni> (the move itself is lots longer than 1 ms)
[08:19:18] <pmbdk> so the rt subsystem is actually also doing a lot of math computations?
[08:19:30] <alex_joni> yes
[08:20:35] <pmbdk> ok, that's where I went wrong then... In my mind I would have put all the math stuff in emctask and them made a big buffer of shmem and make the rt suff only do simple things
[08:20:54] <pmbdk> That's what happens when you guess instead of reading the code... :)
[08:33:03] <alex_joni> pmbdk: what you say has some advantages
[08:33:10] <alex_joni> but it also bears some problems
[08:33:18] <alex_joni> for example if you want to do threading
[08:33:24] <alex_joni> or any other synchronized movements
[08:33:43] <alex_joni> the sync needs to be RT, and motion needs to follow an external source (not time anymore)
[08:34:03] <pmbdk> yes, i see...
[08:34:10] <pmbdk> what's the external source?
[08:34:20] <alex_joni> encoder on the spindle
[08:34:42] <alex_joni> another painful complication is feed override
[08:34:52] <alex_joni> we have 3 sources of feed override
[08:35:06] <alex_joni> iirc :)
[08:35:15] <alex_joni> FO in the GUI
[08:35:28] <alex_joni> adaptive FO while machining
[08:35:44] <alex_joni> and there was something else that I forget right now
[08:36:15] <alex_joni> these are some reasons why it's hard to connect USB thingies to emc2
[08:36:33] <pmbdk> ok, i can see why the encoder following makes sense; if this is not available time is default i guess? (as you can see i'm not an emc expert :-))
[08:37:45] <pmbdk> hopefully though I will be able to do so anyway... :)
[08:38:55] <alex_joni> it depends on the move
[08:39:02] <pmbdk> the only alternative I have is to do everything myself; I did this 20 years ago in fortran and don't want to do it again... :)
[08:39:04] <alex_joni> for encoder synced moves there are special g-codes
[08:39:08] <alex_joni> G33, etc
[08:39:29] <alex_joni> pmbdk: what do you want to accomplish?
[08:42:41] <pmbdk> well, basically i want to control my hexapod with emc...
[08:42:52] <alex_joni> ok, sounds good
[08:43:02] <alex_joni> so you probably want to look at kins first
[08:43:04] <pmbdk> however i don't really need the rt stuff
[08:43:25] <pmbdk> well, i already did the kinematics and my controller works fine this way
[08:43:56] <pmbdk> so what I need is actually a way to interface with my user-space driver
[08:44:19] <pmbdk> since my user-space driver buffers everything there is no rt requirements
[08:44:36] <pmbdk> the electronics on the hexapod takes care of safety critical stuff
[08:44:49] <pmbdk> so in principle i need to:
[08:45:32] <pmbdk> 1) Send movement commands to each of the axis every ms; my driver do all the computations so I only need x/y/z/a/b/c from emc
[08:46:13] <pmbdk> 2) sync time with emc somehow (so emc does not send me too many movement commands)
[08:47:00] <pmbdk> 3) interface to my userspace driver from emc in order to control i/o (again no rt requirements)
[08:47:04] <alex_joni> well.. you can do more things..
[08:47:10] <pmbdk> and thats it... :)
[08:47:15] <alex_joni> I would connect at canon level
[08:47:33] <alex_joni> you get GUI + task + interp
[08:48:40] <pmbdk> And canon level is where? :-)
[08:48:58] <pmbdk> I guess it needs to be after the rt motion computations
[08:48:59] <alex_joni> do you have the sources somewhere?
[08:49:03] <pmbdk> yep
[08:49:07] <alex_joni> canon is still in userlevel
[08:49:11] <alex_joni> no motion computations
[08:49:37] <alex_joni> look at emc2/src/emc/task/emccanon.hh
[08:49:49] <pmbdk> i would _really_ like to have motion do all the work so i got 1 ms samples out.
[08:49:50] <alex_joni> err.. .cc
[08:51:17] <pmbdk> yes, i looked there first; but then i need to do all the motion computations myself... Not that it is that difficult, but still... No need to invent the wheel... :)
[08:51:45] <alex_joni> might be easier to just get the code from src/emc/motion/tp*
[08:52:03] <pmbdk> i was hoping it all could be done by using emc compiled in sim mode
[08:52:27] <alex_joni> well.. theoretically you can do it, but I don't see a way for syncing stuff
[08:52:48] <pmbdk> in sim mode everything runs fine, so I "just" need to interface to the three points mentioned above
[08:53:00] <pmbdk> yes, the syncing also bothers me
[08:53:05] <alex_joni> yes, but in sim mode you don't get 1ms outputs
[08:53:14] <pmbdk> on the other hand; currently it must be done also in sim mode
[08:53:38] <pmbdk> i'm trying to figure out myself what i _do_ get in sim mode... :)
[08:54:18] <pmbdk> if I loiok at motion.c
[08:54:37] <pmbdk> the very last part is enclosed in #ifndef RTAPI
[08:55:00] <pmbdk> if this the sim part?
[08:55:22] <pmbdk> here it seems that it simply waits ~10 ms and then goes on
[08:55:45] <pmbdk> this should be relatively easy to change in order to do external sync
[08:55:50] <pmbdk> with my userspace driver
[08:56:05] <pmbdk> but I don't know if I then miss a lot of stuff
[08:57:31] <alex_joni> RTAPI stuff gets compiled both for sim and RT
[08:57:37] <alex_joni> it just works a bit differently
[08:58:19] <alex_joni> otoh on sim you don't have any timing certainties
[08:58:31] <alex_joni> it can take 1ms this time, and 10 the next time
[08:59:04] <pmbdk> well, that's not a problem
[08:59:06] <pmbdk> for me
[08:59:08] <pmbdk> :)
[08:59:23] <pmbdk> since I need to buffer everything at the user-space driver anyway
[09:00:32] <pmbdk> this obviously means that i get a latency of a few hundred ms between actual movement and computed movement, but this is only critical when something odd happens
[09:00:52] <pmbdk> at these time I need to do some manual tweaing anyway
[09:02:30] <pmbdk> so what you are saying is that the #ifndef RTAPI part of motion.c is not for sim mode?
[09:24:09] <alex_joni> no
[09:31:16] <pmbdk> hmmm, that was ambigous... :-)
[09:31:57] <pmbdk> let me ask another way... :-) Is the #ifndef RTAPI part of motion.c used for sim mode?
[09:34:17] <alex_joni> ifndef is if not defined
[09:34:28] <alex_joni> RTAPI gets defined even if in sim mode
[09:40:51] <pmbdk> ok, so the last part of motion.c is actually not used in sim mode... Then I need to figure out how the syncing (or at least timing) is done in sim mode
[09:53:02] <alex_joni> it's done pretty much like in RT
[09:53:12] <alex_joni> there is a HAL thread (that runs like a pthread iirc)
[09:53:19] <alex_joni> and there are functions added to that thread
[09:53:25] <alex_joni> the functions get executed in order
[09:53:35] <alex_joni> so you would have to add your function to that thread
[09:53:44] <alex_joni> I'd suggest you start reading the HAL docs first
[09:56:31] <pmbdk> ok, i'll do that... :)
[10:37:40] <pmbdk> on a totally unrelated matter: Does AXIS only gets the current position or does it get all positions?
[10:38:08] <alex_joni> what do you mean?
[10:38:28] <pmbdk> So does it need to interpolate between positions it gets or does it have an interface to the actual traversed path
[10:39:11] <pmbdk> I'm assuming that the AXIS GUI does not have an interface to the RT modules as such
[10:39:20] <alex_joni> it doesn't
[10:39:23] <alex_joni> it only talks to task
[10:39:39] <alex_joni> it gets the current position from motion
[10:40:28] <pmbdk> and task only knows about the end-points of all segments of a trajectory
[10:40:31] <pmbdk> (i assume)
[10:40:51] <pmbdk> since motion does the math stuff
[10:41:31] <pmbdk> So in principle AXIS does not know the exact path; only at the points where it interacted with task?
[10:41:50] <pmbdk> I'm probably wrong here... :)
[10:45:20] <alex_joni> there is a periodic update
[10:45:27] <alex_joni> where task gets the current position from motion
[10:45:34] <alex_joni> and AXIS uses that to put the tooltip there
[10:46:07] <alex_joni> AXIS otoh also uses the same interpreter to generate the preview of the part (converting it to lines/arcs, etc and displaying it before motion actually happened)
[10:48:05] <pmbdk> ah... :-) That would have been my next question how that magic happened... :)
[10:49:01] <pmbdk> But in reality AXIS does not know the actual traversed path completely?
[10:58:49] <alex_joni> it does
[10:58:55] <alex_joni> but it doesn't know it's broken down
[10:59:07] <alex_joni> it knows the tooltip will move from 0,0,0 to 10,10,10
[10:59:19] <alex_joni> but it only knows there's a line from start to stop
[11:11:13] <pmbdk> Yes, from the interpreter it knows this; but during milling it will also need the actual path (I assume); this is only known by motion (I assume) at the actual time-point.
[11:11:36] <pmbdk> I assume that there can be a difference from computed and actual path?
[11:39:11] <alex_joni> pmbdk: right
[11:39:18] <alex_joni> there is a periodic update
[11:39:21] <alex_joni> in the status buffer
[11:39:26] <alex_joni> motion puts the current position there
[11:39:30] <alex_joni> and AXIS polls it from there
[11:39:45] <alex_joni> it might be interesting to try if that works good enough in your case too
[11:39:47] <pmbdk> ok...
[11:40:21] <alex_joni> pmbdk: try getting used to emc2/src/emc/usr_intf/halui.cc
[11:40:37] <alex_joni> that's the simplest connection to emc2 using NML channels
[11:54:06] <pmbdk> The reason why I'm asking is that once im done implementing my hexapod stuff (haha, that'll be the day :-)) i'd like to try updating AXIS to visualize the actual milled part (not just path)
[11:56:33] <fenn> pmbdk: look at this if you haven't yet:
http://axis.unpythonic.net/01169689661
[11:56:48] <fenn> though it isnt true 3d, more like 2.5d
[12:01:11] <pmbdk> Cool! :-) Is this based on simple height "rods" you simply cut off?
[12:01:27] <pmbdk> Because for hexapods that will not work... :-(
[12:01:55] <fenn> right
[12:02:02] <pmbdk> Any chance this will be part of newer EMC versions?
[12:02:27] <fenn> uh.. dunno, i think it would be a cool addition to vismach
[12:02:45] <pmbdk> But it sure looks impressive! .-)
[12:03:41] <fenn> it needs to be modified to show the part being changed, instead of just the end result
[12:04:06] <pmbdk> yes, that's would be even more impressive...
[12:07:21] <pmbdk> My idea was to use GTS and simply remove material based on mesh differences
[12:07:36] <pmbdk> But I have no idea about the performance of such a thing
[12:10:56] <pmbdk> alex_joni: I don't think this would be fast enough; I would sure miss a lot of commanded positions....
[12:11:24] <pmbdk> on the other hand i could add a small buffer containing the last N points...
[12:11:40] <pmbdk> and then use nml to get it...
[12:11:45] <pmbdk> hmm, interesting idea....
[12:12:26] <pmbdk> although from what i've read it is not easy to add new nml channels...?
[12:19:02] <fenn> pmbdk: why can't you just write a hal comp for it?
[12:19:24] <fenn> or use emc's kinematics layer
[12:19:32] <fenn> (or both if your hardware is weird enough)
[12:27:29] <pmbdk> fenn: I don't know enough about hal components to know what i'm talking about... :-) Can a hal component get access to the x/y/z coordinates and i/o pins at the same time?
[12:27:58] <pmbdk> i'm currently reading up on the hal users guide
[12:28:29] <pmbdk> and are hal components also used in simulated setups?
[12:28:54] <pmbdk> I would really like to run it in sim mode as it is then much easier to use on non-rt patched kernels
[12:42:38] <jepler> yes, sim uses hal including "realtime" components. no realtime hardware drivers, though.
[12:42:46] <jepler> so you can have 'and2' but not 'hal_parport'
[12:43:18] <pmbdk> ok I can see from the first section in the hal user manual that iocontrol and motion interacts with hal...
[12:43:56] <pmbdk> what "interacts" means is then what i need to read up on... .)
[12:45:34] <jepler> It means that they read hal inputs and drive hal outputs. for instance, motion drives axis.0.motor-pos-cmd with a commanded motor position, and reads axis.1.motor-pos-fb and uses that value to e.g., determine if there is a "following error" condition.
[12:47:27] <pmbdk> so, since I need to interface to both motion and io could I then simply (although I don't know if its simple) write a hal component to get commanded motion and i/o from the gui and then somehow pass this on to a user-space driver?
[12:47:47] <pmbdk> and do this in sim mode... :)
[12:49:50] <jepler> you create a component that has whatever assortment of inputs you need, then you hook them together using hal signals. For instance, if you start with the sim configuration, it has already hooked the pin axis.1.motor-pos-fb to the signal Ypos. If you want the Y motor position, you would also hook Ypos to yourcomp.y-position-input (or whatever you decided to call the pin)
[12:53:07] <jepler> (you hook things together in the "hal" files using the "link" or "net" commands)
[12:59:15] <alex_joni> how has hardy-i386 running?
[13:04:37] <pmbdk> ok, will have to look more into hal components...
[13:08:55] <pmbdk> is there an already existing hal component which works under sim mode and still have access to io and motion?
[13:09:09] <pmbdk> just so i can take a look at the source ...
[13:22:21] <alex_joni> pmbdk: as jepler said, you don't have to have access to io and motion
[13:22:31] <alex_joni> you export hal pins from your component
[13:22:41] <alex_joni> and those get connected to some motion pins and to some io pins
[13:22:55] <alex_joni> (but for this to make sense you need to be acustomed with HAL)
[13:24:15] <pmbdk> as long as I know that it can be done, no problem... Then I just need to read up on things and try it out
[13:24:47] <pmbdk> so this would work in sim mode as well?
[13:25:07] <alex_joni> yes, but not as "well"
[13:25:09] <alex_joni> :)
[13:25:31] <pmbdk> the biggest problem for me now is that i don't know where to start; i think that i have now gotten four answers to the same question... :)
[13:25:50] <pmbdk> alex_joni: not as "well"?
[13:26:14] <alex_joni> yes, RT works better than sim
[13:26:28] <pmbdk> but if the hal approach is the "best" (whatever that is) approach I will go down that road...
[13:27:15] <pmbdk> alex_joni: ah, ok... However for me it's not a problem that i get some latency; however i will _need_ all positions though... So
[13:28:19] <pmbdk> if sim mode means for example that hal pins would not received all position commands (i don't know the correct hal nomenclature) then I would need to go in another direction
[13:28:25] <jepler> with a "rt" component you will get all positions, no matter whether you're running with true or simulated realtime. with a "userspace" component, you will never be guaranteed to get all positions.
[13:28:32] <pmbdk> such as hacking a few hooks in the c code where I know the positions are and the io
[13:28:35] <cradek> how does the external device know when to command the positions? are they timestamped or something?
[13:29:44] <pmbdk> jepler: Then the hal approach will not work... :-(
[13:29:48] <pmbdk> at least in sim mode
[13:30:05] <pmbdk> cradek: yes
[13:31:10] <pmbdk> I setup an internal counter in the microcontroller which i then refer to when I communicate with it from the PC
[13:31:32] <cradek> seems like you need a different kind of 'simulator' that runs the servo thread ahead, generating positions and timestamps, until a queue fills
[13:31:41] <pmbdk> the count frequency is configurable, but currently set to 1 ms update rate
[13:33:40] <pmbdk> yes, I will need to sync the emc sim to my external userspace driver somehow... I was hoping that this could be done simply in the simulated mode for example by slowing down the simulator at a central point... For example in motion or wherever the time is taken care of in the simulated mode
[13:35:31] <cradek> I think you want a different scheme - "hurry up and wait" - generate positions as fast as possible until the queue is full, then try to keep it full.
[13:35:45] <cradek> (maybe I'm just saying the obvious things)
[13:36:04] <pmbdk> yes, that would nice... :)
[13:36:33] <pmbdk> but I think I still need some guidance on where I need to hook things up in the source...
[13:36:41] <pmbdk> I guess HAL is out the question?
[13:36:53] <cradek> I think lots of people are interested in this style of running, where an external device is needed but realtime is not. I hope you can find a nice solution.
[13:37:10] <pmbdk> cradek: me too :)
[13:37:44] <alex_joni> cradek: another option is using sampler
[13:37:51] <jepler> http://emergent.unpy.net/files/sandbox/positionlog.hal http://emergent.unpy.net/files/sandbox/positionlog-ini.patch
[13:37:56] <jepler> that's what I was just toying with
[13:38:01] <pmbdk> Actually before I knew much other than the name of emc I thought that this was already an integral part of emc
[13:38:07] <cradek> from listening to jepler it sounds like you can't just use hal/sampler/etc if you don't have realtime
[13:38:22] <alex_joni> right.. I wouldn't trust it on sim
[13:38:51] <cradek> pmbdk: no, emc doesn't currently need/use these kinds of external devices. they are very limiting.
[13:38:53] <jepler> cradek: you can modify the way rtapi_app tries to approximate the requested thread timing
[13:38:58] <jepler> cradek: I mean, one could
[13:39:20] <jepler> cradek: for instance you could modify rtapi_app to run as fast as possible, and the sampler "realtime component" to sleep when the queue is full.
[13:39:42] <alex_joni> how about block instead of sleep?
[13:39:47] <alex_joni> and halt the whole thread?
[13:39:58] <jepler> yes, you would have to halt the whole (only) thread
[13:40:22] <alex_joni> s/you/one/
[13:40:25] <alex_joni> :P
[13:40:58] <jepler> anyway, once you've modified your configuration as shown above, you can run 'halsampler' and it will spew 1ms-sampled positions onto the terminal. Or you could run 'halsampler|yourapp' to put that on yourapp's standard input, or popen("halsampler") inside yourapp
[13:42:38] <pmbdk> jepler: this sounds too easy... :-)
[13:43:08] <pmbdk> but I understand you correctly in assuming that this will only work with RT?
[13:43:23] <jepler> no, I was running it on a machine with simulated realtime
[13:43:33] <pmbdk> unless some modifications are made in sim mode
[13:43:42] <pmbdk> jepler: :-)
[13:43:57] <jepler> but there's no guarantee that it won't fall behind
[13:44:01] <pmbdk> I will have to try this at home! :)
[13:44:03] <jepler> so it depends what you mean by "work"
[13:44:19] <pmbdk> "work" is "work when I test it" .-)
[13:44:46] <pmbdk> No, obviously I would at least need to have an indicator that I falled behind...
[13:44:47] <jepler> I believe it does what I said, but there's no guarantee that the average rate at which 1ms-sampled positions are given to you is not (say) 1.001ms
[13:45:16] <pmbdk> ok, so I still need to sync it somehow of course....
[13:45:36] <pmbdk> is there any way to sens messages to the timing "subsystem" some how?
[13:45:41] <jepler> no
[13:45:50] <pmbdk> jepler: :-(
[13:46:02] <jepler> there's certainly no "try harder" button
[13:46:44] <pmbdk> do you know where the timing sor sim mode is made?
[13:46:52] <pmbdk> s/sor/for
[13:46:55] <jepler> in src/rtapi/rtapi_sim.c there is a function sim_rtapi_run_threads. it calls the function maybe_sleep.
[13:47:29] <pmbdk> thanks....
[13:47:49] <pmbdk> so somehow I will need to change that... And to add an interface of some sorts to this....
[13:47:57] <pmbdk> Piece of cake... .-)
[13:51:30] <pmbdk> probably a stup question based on my limited knowledge of HAL: Wouldn't it be possible in the HAL component (may a customized version of it) to send something back in order to slow the timing down whenever say half the buffer size is reached and then back again when it goes the other way?
[13:52:05] <pmbdk> So something like changing the timing from ~0 ms to ~2 ms whenever I want to run a t 1 ms
[13:54:02] <pmbdk> so my question is really: Can I change something in order for the hal component to send something back to the sim_rtapi functions
[13:54:14] <alex_joni> not as it is
[13:54:42] <alex_joni> you would have to add some "delay" parameter which gets used between thread executions
[13:55:14] <pmbdk> alex_joni: yes, something like that...
[13:55:34] <pmbdk> I _really_ have to read up on the hal components... :)
[13:55:38] <alex_joni> yes
[13:59:30] <skunkworks_> alex_joni: are you traveling?
[14:06:39] <alex_joni> skunkworks_: not atm
[14:06:47] <alex_joni> will be next week
[14:08:59] <skunkworks_> ok - you wanted me to remind you. You had some links on the puma iirc
[14:14:31] <jepler> http://emergent.unpy.net/files/sandbox/timer_control.patch
[14:16:03] <jepler> but with this patch you've lost all relationship to external time, except if it's enforced by whatever is reading from halsampler in userspace
[14:24:58] <pmbdk> jepler: Cool! :-)
[14:25:39] <pmbdk> Can you leave it in your sandbox for a few hours? :-)
[14:26:38] <jepler> pmbdk: oh stuff has stayed in there for *years*
[14:26:46] <pmbdk> I guess the external time relationship is lost in any case in sim mode...
[14:26:56] <pmbdk> jepler: :-)
[14:27:43] <pmbdk> as long as I know that the samples are equidistant from emc's point of view...
[14:28:38] <pmbdk> In any case this is a great starting point for me!
[14:32:43] <jepler> yes; in sampler.c you're getting 1ms samples. in halsampler.c you are getting all those 1ms samples unless it prints "overrun".
[14:33:37] <jepler> (well, not necessarily 1ms -- whatever the period is of the thread you add the sampler to)
[14:34:36] <pmbdk> jepler: yep... :-)
[14:34:44] <pmbdk> thanks alot! :-)
[14:34:57] <pmbdk> i can't wait to get home a try it out...
[14:35:04] <pmbdk> s/s/and
[14:35:20] <pmbdk> dammit i can't type...
[14:41:43] <pmbdk> btw if anyone is interested in seing a crappy video of the hexapod doing absolutely nothing than moving, I can upload it somewhere... :-)
[14:42:38] <fenn> oo oo
[14:43:00] <fenn> i do
[14:51:57] <pmbdk> ok, uploaded it...
[14:52:26] <pmbdk> I should mention that this is a crappy video from the first time we tested it after putting upside/down
[14:52:49] <pmbdk> the video is taken using a mobile phone, so the quality is really lousy
[14:53:38] <pmbdk> and the video format is some weird 3gp which will probably not run off-the-shelf on linux...
[14:53:44] <pmbdk> quicktime is needed afaik
[14:53:47] <pmbdk> http://bohn-hansen.dk/usenet/MOV00020.3gp
[14:58:18] <rayh> shows fine here with 8.04
[15:01:51] <fenn> that looks very well made
[15:02:08] <pmbdk> ok, I have never actually tried it on linux... I figured it was some proprietary format which only QT knew anything about... :-)
[15:02:51] <pmbdk> qt as in quicktime, not the toolkit
[15:03:19] <pmbdk> fenn: Thanks... :-)
[15:03:46] <pmbdk> It did take some time to do... But it's good fun... :-)
[15:04:35] <pmbdk> I can't take crdit for everything, though, one of my colleagues did most of the mechanics
[15:04:55] <skunkworks_> are you using emc to run it?
[15:05:12] <pmbdk> nope, but hopefully I will be soon... :-)
[15:05:19] <cradek> neat, that looks great
[15:05:39] <pmbdk> I "just" need to add an interface for non-realtime machines to emc... :-)
[15:06:10] <pmbdk> with some help from you guys... :-)
[15:06:31] <cradek> well you don't NEED to. running in realtime would work just fine and guarantee you have no queue starvation ever.
[15:07:10] <skunkworks_> that is pretty cool. - what are you running with it now?
[15:08:52] <rayh> pmbdk Why do you think it is easier to modify EMC2 to the needs of your machine, than your machine to the ordinary signals provided by EMC for such a machine.
[15:09:01] <pmbdk> cradek: Well, one of my design goals was to make the interface to the PC very limited... I really don't like to have a modern PC with it's complexities running anything dangerous... And believe me, this machine _is_ dangerous... :-)
[15:11:13] <fenn> i hope you dont think your ad-hoc software is any safer
[15:11:14] <pmbdk> I also needed electronics doing fast pulse generation, i.e. > 400 kHz, and although I could probably have used something emc supported, by original design goal of separating the PC and the machine left me with some custom electronics
[15:11:37] <pmbdk> fenn: Actually I'
[15:12:22] <pmbdk> fenn: Actually I'm quite sure that my customized firmware (which runs the critical part of the machine) is safer than anything running on a pc... :-) Simply due to it's simplicity
[15:12:41] <cradek> what do you mean ad-hoc software?
[15:12:52] <fenn> perhaps but you still shouldn't rely on anything electronic for safety
[15:13:34] <pmbdk> fenn: Well, at some points you need electronics sensors... Mechanics can not do everything... :-)
[15:13:53] <fenn> cradek: i'm referring to the fact that his firmware has probably not been tested very thoroughly
[15:14:39] <pmbdk> I bet my magnetic contact on the door to the room - which is directly connected to the power - is safer than anything mechanic I could come up with... :-)
[15:15:01] <fenn> yep, that's electrical though, not electronic
[15:17:41] <pmbdk> fenn: The firmware has been tested quite thoroughly; even though emc might have a lot of users and have been tested by many persons it is extremely large and complex and for this reason alone I think I can safely say that by very simple firmware if better tested than emc (no offense:-)). In any case the operating system also has an impact, and I know for a fact that during the test of the...
[15:17:43] <pmbdk> ...controller two of my PC's died and the controller still runs with no problems
[15:19:57] <rayh> This controller does all the kinematics and stepper driving?
[15:20:45] <rayh> If so, what information do you send it to move in X from 0 to 1?
[15:22:34] <pmbdk> The controller is very simple; it simply takes commands from the PC and steps the servos as well as control the I/O and doing safety critical checks. In principle I could probably have used some of emc's supported boards, but at the time we began our development we had no idea what emc was... :-)
[15:23:42] <pmbdk> The PC implements the kinematics (this runs in something like 3x realtime with 1 ms sample rate so I would have needed a PC on the controller anyway to implement this on the controller)
[15:25:04] <rayh> What I'm trying to get at is what language does your controller use to get information from the PC?
[15:25:46] <rayh> What do the commands look like?
[15:26:33] <pmbdk> rayh: Oh, that's a home-made and extremely simple protocol.
[15:27:44] <rayh> No problem. I'm just asking how my PC would tell your controller to move from X0 to X1 at a feedrate of 45mm/min.
[15:27:47] <pmbdk> something like <start of frame> N x<pulses per next timestep><checksum>
[15:27:52] <pmbdk> for pulses
[15:28:15] <pmbdk> something even simpler for IO
[15:28:43] <pmbdk> rayh: This is the task of my user-space driver
[15:30:15] <rayh> And you would send <start of frame> N x<pulses per next timestep><checksum> for each motor?
[15:30:28] <pmbdk> One of the great things about separating the suff is also that it is quite difficult to do anything harmful (hexapods have many more degrees of freedom in the harmful-area :-)) sine the controller have limits on the extends
[15:31:07] <pmbdk> No, the N x is for N axes. I actually have 7 axes... :-)
[15:31:07] <rayh> I'm not asking why, I'm asking how?
[15:32:07] <rayh> So the x<pulses per next timestep> is the X command?
[15:32:39] <pmbdk> So for each timepoint (say for example 1 ms) I send 7 pulse integers within a single frame
[15:33:10] <rayh> Okay.
[15:33:21] <pmbdk> So something like <start of frame> <pulses per next timestep for axis 1>...<pulses per next timestep for axis 7> <checksum>
[15:33:32] <pmbdk> at the controller it is buffered
[15:33:42] <rayh> Sure.
[15:34:58] <rayh> But each of <pulses per next timestep for axis #> is simply a command to step a single motor?
[15:35:00] <pmbdk> so probably the most simple language to do such stuf... :-)
[15:35:12] <pmbdk> Yes
[15:35:31] <pmbdk> <start of frame> also indicates what kind of data comes after
[15:35:54] <pmbdk> and the sync is done by sending back ack from the controller
[15:36:12] <pmbdk> it really couldn't be simpler...
[15:36:29] <rayh> So there are no kinematics translation from individual motors to a Cartesian systems down on that controller?
[15:37:34] <pmbdk> in principle not... I did however implement something simple in order to test for obvious wrong axis motion
[15:38:02] <pmbdk> it _is_ still possible to some some weird motion, but not likely though
[15:38:27] <rayh> I see.
[15:38:31] <pmbdk> and by weird I mean weird as in harming one or several of the legs
[15:38:50] <pmbdk> I did this once; don't want to do it again... :)
[15:38:59] <fenn> what happened?
[15:39:35] <pmbdk> Well, during testing of the legs I simply sent out pulses to see how it looked
[15:39:57] <rayh> So EMC2 would need to run a hexapod kinematic module and then somehow send the resulting number of steps for each motor to your controller.
[15:40:06] <pmbdk> there were no check of anything and the magnetic inductors were not used... :)
[15:40:20] <rayh> I know a bit about hexapod singularities. They can be scary.
[15:40:47] <pmbdk> at some point my collegue needed to do some tests and just spawned the very limited test gui and entered some wrong number
[15:41:52] <rayh> I've done that.
[15:42:00] <pmbdk> it took something like 400 ms before the alarm on the servo went off and closed down... A hexapod with 6 degress of dreedom is not fun when suddenly one of the degress are missing and the other 5 servos still runs
[15:42:48] <pmbdk> instead of just shutting down the power my colleague actually jumb in between the legs to save the leg...
[15:42:55] <pmbdk> Beleive me, THAT was scary!
[15:43:00] <fenn> bad idea
[15:43:07] <pmbdk> s/jumb/jumped
[15:43:18] <fenn> i still dont understand what went wrong though
[15:43:37] <pmbdk> VERY bad idea.... Luckily eh wasn't harmed...
[15:44:20] <pmbdk> well first of all at that point the hexapod was upside/down wrt. to the video
[15:44:34] <rayh> The original K&T hexapod would occasionally pick the wrong kinematic solution and rip the balls out of a ballnut.
[15:45:25] <pmbdk> when you only have 5 working servos left and the sixth one is drifting the legs can at some point touch one of the other legs
[15:45:40] <pmbdk> this can also happen with 6 servos on of course...
[15:46:32] <skunkworks_> rayh: how was that fixed? pick the solution closest to the previous solution?
[15:46:49] <rayh> That is how we do it.
[15:47:38] <pmbdk> rayh: He... :-) I have implemented sanity checks on virtually everythin in the userspace driver and we have tested it a lot so hopefully this will not happen... But who knows when some day we need to change the geometry slightly... :-)
[15:47:40] <rayh> But we don't have any way of preventing the platform from moving into a singularity.
[15:48:02] <rayh> we=emc2
[15:48:12] <fenn> or banging into a wall :)
[15:48:20] <fenn> (different kind of singularity :)
[15:48:26] <pmbdk> fenn: Tried that to... :-)
[15:48:49] <rayh> That is the walking version of a hexapod.
[15:49:51] <rayh> But pmbdk aren't you thinking of replacing that user space driver with something related to EMC2?
[15:50:02] <pmbdk> Well you don't need a walking version to do that... .-)
[15:51:40] <rayh> EMC2 has good joint or axis travel limits in software.
[15:52:02] <rayh> What we don't have is a complex work envelope definition.
[15:52:45] <rayh> For a trivial kinematic machine this might exclude a vice or other work holding device.
[15:53:22] <rayh> For a puma type robot it might be the reach and exclude the pedestal.
[15:53:55] <rayh> For a Hexapod it would be all the space inside the singularities.
[15:54:42] <pmbdk> I should mention that the Hexapod we have currently have something like 96 calibration parameters, so it's not really a generic hexapod... :-)
[16:04:00] <rayh> The geometry you use is very similar to the NIST cable geometry.
[16:04:34] <pmbdk> Well I guess all hexapods have somewhat equivalent geometries... :-)
[16:05:12] <rayh> Have you tried the programs that jeppler wrote for you?
[16:05:23] <pmbdk> The most significant change is in the joints I guess
[16:05:41] <pmbdk> nope, im not home yet...
[16:06:01] <pmbdk> but I really look forward to it...
[16:06:03] <pmbdk> :)
[16:06:20] <rayh> By joints you mean the swivels that you made for the ends of the arms?
[16:07:55] <pmbdk> Yes...
[16:08:07] <pmbdk> I thought they were named joints... :-)
[16:11:00] <rayh> I'm sure they are. In the EMC literature we refer to joint as the entire arm including motor, leadscrew, and ends.
[16:11:13] <pmbdk> i better leave now; thanks for all the help guys!
[16:11:21] <rayh> catch you later.
[16:11:33] <pmbdk> ah... .-)
[16:11:48] <pmbdk> that's a big joint...
[16:12:20] <pmbdk> will probably be back this evening (gmt)
[16:21:33] <jepler> does the gmt even have "evening"?
[16:22:39] <alex_joni> no, they only have morning there :)
[16:23:54] <fenn> funny, i'm reading an article titled "
[16:23:55] <fenn> 8 am of the world"
[16:24:41] <alex_joni> rayh: around?
[16:24:50] <rayh> Yep
[17:20:39] <alex_joni> update should be out for rtai
[17:29:07] <rayh> Yep and I just installed it on one of the fest boxes without any problems.
[17:34:21] <alex_joni> thanks for the confirmation