Back
[14:31:11] <SWPadnos> skunkworks, yes - I've been in Dallas, and I head for LA tomorrow morning
[14:31:24] <skunkworks_> yikes.
[14:31:29] <skunkworks_> Thanks SWPadnos
[14:31:41] <skunkworks_> Has it gone smooth?
[14:31:46] <SWPadnos> then I get home at Midnight Monday, and leave for Houston at 6 AM Wednesday :)
[14:31:53] <SWPadnos> smooth as 100-grit sandpaper
[14:31:57] <SWPadnos> maybe 150-grit
[14:32:50] <skunkworks_> well that's............ good
[14:32:56] <SWPadnos> yeah, exactly
[14:33:11] <SWPadnos> I couldn't get the power thing worked out, so we're going with plan B
[14:33:24] <skunkworks_> the atoms shutting down?
[14:33:41] <SWPadnos> oh - different power problem
[14:33:50] <SWPadnos> the atoms do pause from time to time, but it may be the software
[14:33:51] <skunkworks_> ah
[14:33:56] <SWPadnos> they did it inside, after only a few minutes of use
[14:39:10] <skunkworks_> was this the vma's?
[14:42:05] <SWPadnos> no, they backed out
[14:42:08] <SWPadnos> the Emmys this weekend
[15:43:07] <steve_stallings> steve_stallings is now known as steves_logging
[16:19:42] <skunkworks_> pcw_home: there seems to be an incling that someone is working on a mesa plugin for mach. Heard anything? (wondering how that would work - have to use your motion firmware I assume)
[16:21:47] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=645512&postcount=24
[17:03:45] <pcw_home> Yes, theres a Alpha quality plugin now that supports both our PCI cards (5I20,5I22,5I23) and our 7I43 in USB mode
[17:03:47] <pcw_home> These do use the microcontroller based configuration (SoftDMC) so they run the PID loop and position interpolation locally
[17:03:49] <pcw_home> These were written by the same guy the wrote much of the Galil plugins
[17:04:37] <skunkworks_> neat
[17:04:59] <cradek> I have always wondered if mach can home to index with any of these external motion control cards
[17:05:37] <SWPadnos> as long as the driver supports it, sure. Mach would just set its internal step count/position to zero
[17:06:01] <SWPadnos> how to deal with errors / aborts is another story
[17:06:21] <cradek> I can imagine easily doing without things like rigid tapping - buy a tapping head of some kind. but I can't imagine a real machine without index homing.
[17:06:23] <pcw_home> SoftDMC certainly can home to index, whether the driver does or not I don't know
[17:06:48] <skunkworks_> I thought softdmc only did strait line interp
[17:07:25] <pcw_home> I think much of that kind of thing is done with gearing...
[17:07:26] <pcw_home> Steve M did a lot of work with SoftDMC gearing
[17:08:00] <pcw_home> It can do cubic but the mach drive just uses linear (PVT packets)
[17:08:18] <pcw_home> (driver)
[17:08:20] <skunkworks_> that should open up a larger market for you
[17:08:59] <pcw_home> Also more crowded market...
[17:09:22] <skunkworks_> heh - and with everyone wanting to use step/dir drives.....
[17:10:46] <pcw_home> Yep, we dont even support step/dir with SoftDMC yet
[17:10:47] <pcw_home> but we will in version 5 (it will graft HostMot2's I/O onto SoftDMC)
[17:13:23] <pcw_home> This should benefit HostMot2 as well. the main 32 bit SoftDMC CPU used in V5 will be
[17:13:25] <pcw_home> the one we use for the HostMot2 resolver interface as well
[17:18:02] <pcw_home> I have a driver question concerning SPI, wanting opinions...
[17:18:04] <pcw_home> I think Sebastian wanted some kind of plug-in architecture
[17:18:06] <pcw_home> for support of specific SPI devices. Is a HAL component an appropriate
[17:18:07] <pcw_home> place for specific device support? It seems like a nice open, easy to customize
[17:18:09] <pcw_home> located for device specific code (assuming the driver supplies some generic low
[17:18:10] <pcw_home> level access routines)
[17:19:11] <pcw_home> (location)
[18:08:40] <pcw_home> bbl
[18:11:07] <cradek> we have hal components for a few particular modbus devices like the automation direct GS2 vfd family. I think that's appropriate and your question seems like the same situation
[18:14:22] <pcw_home> Yes, a similar situation. the only problem I see is that support of DMA would require some sort of double buffering
[18:14:23] <pcw_home> when the component just read/wrote to the DMA buffer
[18:15:14] <pcw_home> rbbl
[18:50:28] <PCW> (where the component)
[23:33:00] <dgarr> for consideration: hal_ppmc.c parameters to pins:
http://www.panix.com/~dgarrett/patch/0001-parameters-to-pins.patchi've ran it on my hw for a few days, it is servo only, i don't have a way to test stepper but the mods are pretty generic
[23:33:14] <dgarr> oops, link is
http://www.panix.com/~dgarrett/patch/0001-parameters-to-pins.patch
[23:35:09] <jepler> just curious which of those you found it useful to use as pins
[23:36:22] <jepler> there's a problem that I haven't exactly understood how to fix, and this change suffers from it as well
[23:36:23] <dgarr> more of an exercise in params to pins, it also is useful that all my alias lines are same instead of some for params, some for pins
[23:36:25] <jepler> + /* user max velocity is non-zero and positive, compare to max_freq */
[23:36:28] <jepler> + if ( ( *(sg->max_vel) * abs_scale) > ch_max_freq) {
[23:36:30] <jepler> +/* user max velocity is too high, lower it */
[23:36:33] <jepler> + *(sg->max_vel) = ch_max_freq / abs_scale;
[23:36:42] <jepler> technically the component is wrong to drive a value on to *(sg->max_vel) because it's an IN pin in hal terms
[23:37:17] <jepler> but you can't change it to an IO pin because you can't link an OUT to an IO
[23:38:12] <jepler> (I suspect but don't know that this kind of mistake is already in components we've converted to all pins..)
[23:40:57] <mozmck> what can you link to an IO pin?
[23:41:17] <jepler> mozmck: IN pins and other IO pins
[23:42:13] <dgarr> jepler: so i should leave max_vel as a param?
[23:42:33] <mozmck> so could you link three IO pins together?
[23:43:01] <jepler> mozmck: yes
[23:50:29] <jepler> dgarr: I'm not sure what to recommend
[23:52:11] <jepler> dgarr: (A) leave problematic things as params (B) convert them to pins, and store the "converted to be in range" value in a new field (C) convert them to pins, and store the "converted to be in range" value to a new *parameter* (so the user can e.g., still see the max step rate in inches per second) (D) call the whole thing off
[23:52:16] <jepler> just a few possibilities..
[23:53:23] <mozmck> are we trying to get rid of params?
[23:53:59] <jepler> mozmck: what we've discovered is that our inventive users can come up with reasons to vary at runtime things we thought were not likely to vary
[23:54:15] <jepler> (for instance, stepconf wants to vary stepgen's acceleration and velocity limits dynamically)
[23:54:55] <jepler> mozmck: so that gave rise to the idea that we should just convert "everything" to pins
[23:55:49] <mozmck> ah, I see. so params can't be changed during a run then...
[23:56:04] <jepler> you can "setp" them anytime you like
[23:56:07] <jepler> from halcmd
[23:56:19] <jepler> but you can't connect a param to a signal
[23:56:31] <jepler> so a component can't make another component's parameter change
[23:56:57] <mozmck> I see.
[23:57:55] <jepler> dgarr: (E) get commit access so that you don't have to ask before your changes .. that's how all my ill-considered changes get in
[23:58:07] <jepler> s/before your/before committing your/
[23:58:31] <dgarr> jepler: i think (D) without some other guidance that would be applicable in general