Back
[01:32:40] <jmkasunich> hi guys
[01:32:51] <SWPadnos> hi jmk
[01:32:55] <jmkasunich> saw the discussion about quantity discount on m5i20
[01:33:00] <jmkasunich> I'm in!
[01:33:08] <SWPadnos> cool
[01:33:21] <jmkasunich> (I have already decided I'm gonna buy one, and was planning to do it before year end)
[01:33:29] <SWPadnos> by Fest time, I may be making robots that use them, so we may not need many people to join the fun
[01:34:19] <SWPadnos> I wonder what happens if you have two cards in a system ...
[01:34:22] <jmkasunich> the savings is $40 each, so the cost of re-shipping isn't too out of hand
[01:34:34] <jmkasunich> have to ask peter at mesa
[01:34:54] <jmkasunich> I would hope they play nice together
[01:34:56] <SWPadnos> no - it's a great deal. basically buy 4 get one free
[01:35:16] <SWPadnos> I would think so, but I imagine wanting different code on them as well
[01:35:22] <jmkasunich> cradek: jepler: still here?
[01:35:45] <jmkasunich> on the topic of stepgen silently lowering its max,
[01:35:48] <SWPadnos> I'd love to make an isolated version of that card though - the "direct to the chip" routing makes me nervous
[01:36:18] <jmkasunich> I have no problem with printing a message if the users asks for more than the component can deliver
[01:36:46] <jmkasunich> but I am adamantly opposed to the "refuse to init if the params are no good" idea (even if it could be done)
[01:36:54] <jmkasunich> I want to keep the interactive capability of HAL
[01:37:06] <SWPadnos> yeah - you have to be able to tune from an initial condition that won't work
[01:37:21] <jmkasunich> if you ask for too much, it sets the value to the maximum allowable, and now you know
[01:38:04] <jmkasunich> and I want people to be able to change maxfreq (or steplen or dirhold) even after running for hours
[01:38:18] <SWPadnos> what do you think of adding input pins to the motion controller, so it can get hardware capabilities from the drivers?
[01:38:46] <jmkasunich> then the drivers need to export all that, and the config needs to be more complex to pass all of it around
[01:39:14] <SWPadnos> well, the config can just send it to the lower level (like PID and stepgen), and then pass it up to the motion controller "automagically"
[01:39:27] <SWPadnos> err - which then pass it up ...
[01:39:29] <jmkasunich> IMHO, why should we make the config more complex, with more signals, just so that people who can't deal with the complexity we have now can avoid using a fscking calculator?
[01:40:10] <SWPadnos> the main reason is so that users aren't snowed by the work they have to do to configure EMC
[01:40:43] <jmkasunich> is maintaining a little headroom for the stepper really so tough?
[01:40:45] <SWPadnos> EMC is very flexible - well beyone what most people need, but it is way more complex to configure than similar software
[01:40:57] <SWPadnos> yes, that doubles the number of config parameters ...
[01:41:20] <SWPadnos> note that Ed Nisley, and electrical engineer and programmer, is having a hard time worting out which things affect what
[01:41:44] <SWPadnos> working
[01:42:36] <jmkasunich> I just have a major issue with adding complexity to hide complexity
[01:42:53] <SWPadnos> I can agree with that
[01:43:13] <jmkasunich> and I can't see any even remotely non-complex way to do what you are talking about
[01:43:46] <SWPadnos> well, add linkpp pid.n.max_vel -> axis.n.max_vel
[01:44:36] <jmkasunich> and now is axis.n.max_vel going to interact with the max_vel that comes from the ini file?
[01:44:45] <jmkasunich> silently use the lower of the two? that will leave folks just as confused
[01:44:48] <SWPadnos> the ini file number would go to the PID, not the motion controller
[01:44:57] <jmkasunich> wtf?
[01:45:02] <SWPadnos> the motion controller would get the value from the lower level
[01:45:05] <SWPadnos> driver
[01:45:06] <jmkasunich> first, what pid?
[01:45:16] <SWPadnos> or stepgen - sorry
[01:45:18] <jmkasunich> ok
[01:45:42] <SWPadnos> so you set steps/inch, and max_vel for the stepgen, and that can feed a number back up to motion saying "don't ask for more than this"
[01:45:49] <jmkasunich> so what if there is no lower level? (sim for example)
[01:45:50] <SWPadnos> and this can be 95% of max, if you want
[01:46:09] <SWPadnos> the sim hal files can set the pin directly from the ini
[01:46:38] <SWPadnos> it just moves it out from the silent load from motion (plus the not-so-silent load for HAL components) into just the HAL ini read
[01:46:55] <jmkasunich> if you are proposing replacing the inifile -> motion controller channel with halpin -> motion controller, I can almost see that, except,
[01:47:03] <SWPadnos> I think it ends up being a simplification
[01:47:05] <jmkasunich> what about the user space code that also uses those limits?
[01:47:14] <jmkasunich> task is aware of them too you know
[01:47:16] <SWPadnos> well, that could be a problem ;)
[01:47:44] <SWPadnos> but some clever NML hacking by alex could solve that ;)
[01:48:05] <jmkasunich> the idea of having a set of HAL signals that conveys the actual "stuff" (realtime signals) and a whole nother set, perhaps even larger than the first set, just for config stuff, bothers me
[01:48:28] <SWPadnos> the scheme does fit into a good paradigm though - the lower level code tells the upper level code what it can do, and the upper level code adjusts to that information
[01:49:08] <SWPadnos> in concept, it's like auto-discovery of capabilities (it's just that 'auto" is left to the user in the INI for a lot of things)
[01:49:10] <jmkasunich> so do you use that approach for the axis limits, and keep the TP limits in the [TRAJ] section?
[01:49:20] <SWPadnos> yes, the user still may want a limit
[01:49:33] <SWPadnos> separate from the machine capability, that is
[01:49:42] <SWPadnos> and yes, you'd use the lower of the two
[01:50:10] <jmkasunich> TP already uses the lower ;-)
[01:50:12] <SWPadnos> in essence, that's what you do now, but the user has to specify all the numbers in the AXIS_N sections, instead of having the computer figure them out instead
[01:50:17] <SWPadnos> right :)
[01:50:31] <jmkasunich> well, that will _not_ change
[01:50:44] <jmkasunich> because the computer can't figure out what accel or step rate will make the motors puke
[01:51:09] <SWPadnos> right - I guess the question is - what do you do when the machien can't do what the user asks - is it an error or do you silently use the lower number?
[01:51:41] <jmkasunich> machine = motors? (the usual case) or machine = stepgen (because of steplen, etc) which IMO is a rarer case
[01:51:47] <SWPadnos> sure, but the stepgen user could test accel and vel in steps/sec or steps/sec^2, and have stepgen tell motion how many IPS that is
[01:52:13] <jmkasunich> funny, thats how maxvel and maxacc were originally specified
[01:52:33] <SWPadnos> and they aren't now because motion needs them in IPS ...
[01:52:34] <jmkasunich> after NIST-fest I changed them to use ini file units so we could pull the data from the ini
[01:52:42] <SWPadnos> right ;)
[01:52:51] <jmkasunich> because people were too lazy to use calculators ;-)
[01:52:59] <SWPadnos> if stepgen gave the info in motion-usable units, then all would be well
[01:53:24] <SWPadnos> I'm not saying that using steps/sec(or sec^2) is good, but it may be good for some people
[01:53:30] <jmkasunich> so you want stepgen to _get_ the info on one pin (or param) and ship it back out on another?
[01:53:52] <SWPadnos> also for PID - you set PID_max{vel,accel}, and it tells motion "don't go above this, or we're in trouble"
[01:53:58] <SWPadnos> maybe
[01:54:28] <SWPadnos> it can get the info from the ini, or from a calculation of step{space,len}, and output the lower of the two
[01:54:36] <jmkasunich> PID has no reason whatsoever to know max acc or vel
[01:54:49] <SWPadnos> err - true - nevermind :)
[01:56:08] <SWPadnos> I guess the thought process was something like what does the user know about the machine (mechanically/electrically), and what can emc figure out for them?
[01:58:20] <jmkasunich> in the past I've talked about turning all parameters into pins
[01:58:33] <jmkasunich> that is a step in the direction you want
[01:58:49] <SWPadnos> well, I hadn't really thought it through all the way, but I do like the idea that somehow the data about the hardware goes to the hardware driver, and the hardware driver tells the motion controller what it can do
[01:58:55] <jmkasunich> because then you _could_ connect them if you wanted to
[01:59:12] <jmkasunich> that idea sounds nice
[01:59:31] <jmkasunich> but in the real world, just about any driver will actually be getting info about the motors, etc, from a human being
[01:59:38] <SWPadnos> SMODTDTPTT
[01:59:53] <jmkasunich> ?
[02:00:19] <SWPadnos> Simple Matter Of Discussion Then Design Then Programming Then Testing
[03:43:41] <ve7it> ve7it is now known as LawrenceG
[04:02:20] <jepler> jmkasunich: I'm back now
[04:02:54] <jmkasunich> hi
[04:03:16] <jepler> jmkasunich: I don't want to make hal or rtapi interactive per se, but when an error message is printed with rtapi_msg(RTAPI_MSG_ERR , ...) it would be nice if it could get back to the user with the nice facility that emc has, but the base kernel doesn't
[04:03:59] <jmkasunich> agreed
[04:07:08] <jmkasunich> if you are running an interactive halcmd, it would be nice if it could print the messages
[04:09:45] <jepler> hm
[04:10:11] <jepler> I envisioned a function pointer in kernelspace, which is called if not NULL instead of calling printk(). that would cover the emc case but not the halcmd case.
[04:10:26] <jmkasunich> whats the difference?
[04:10:39] <jepler> the kernel can't call code in halcmd through a function pointer
[04:10:53] <jmkasunich> how can it call emc?
[04:11:08] <jepler> emc must pass that buffer back to userspace in shared memory or something
[04:11:16] <jepler> I don't really know the details, but somebody made it work
[04:11:23] <jmkasunich> oh, the "report-error" mechanism?
[04:11:25] <jepler> right
[04:11:33] <jmkasunich> dunno how that works
[04:11:50] <jepler> I suppose halcmd could do something similar with a shared memory block
[04:12:02] <jmkasunich> so you are just talking about transferring the message from one kernel thing to another, and using that "things" kernel->user channel
[04:12:39] <jepler> yes
[04:13:03] <jepler> as with many of my ideas, it may turn out to be a mess when implemented
[04:13:15] <jepler> goodnight
[04:13:25] <jmkasunich> goodnight
[17:17:07] <cradek> grrrr!
[17:17:12] <alex_joni> cradek: ?
[17:18:12] <SWPadnos> heh
[17:18:22] <SWPadnos> the old stepper "get out the calculator" problem ;)
[17:22:45] <SWPadnos> I like this Bjarne Stroustrup quote: "Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it."
[17:22:58] <alex_joni> he's right
[17:23:20] <SWPadnos> yep
[17:24:06] <jepler> * jepler tries to stick in a snark about how bad C++ sucks but fails
[17:24:07] <alex_joni> still don't like the guy for c++
[17:24:11] <SWPadnos> heh
[17:24:29] <cradek> alex_joni: you're very brave for helping alex, thank you
[17:25:06] <alex_joni> cradek: :-)
[17:25:31] <alex_joni> I resisted my urge for beeing more sarcastic
[17:27:10] <jepler> good for you
[17:27:12] <jepler> I can never resist
[17:27:21] <jepler> unless I never write the message in the first place
[17:27:29] <cradek> I couldn't either, so I kept quiet
[17:27:39] <SWPadnos> heh - lots of that going around ;)
[17:27:50] <jepler> in fact I've been ignoring the whole thread
[17:28:20] <cradek> I think we probably should have commented out limit/home switch setups in the stepper configs
[17:28:38] <SWPadnos> that's true
[17:31:04] <SWPadnos> interview with Stroustrup, from which that quote came:
http://www.techreview.com/InfoTech/17831/
[17:46:37] <skunkworks> jepler: cradek: how did axis come about?
[18:31:30] <jepler> skunkworks: It started as a standalone g-code previewer.
[18:31:43] <jepler> skunkworks: emc1 had one, called gplot (I think)
[18:31:50] <jepler> skunkworks: but the license was unclear and it was hard to use
[18:32:08] <jepler> skunkworks: so I wrote a g-code parser in Python, and a renderer, and that was called "rs274py" for awhile
[18:32:52] <jepler> this was in october or november of that year
[18:33:14] <jepler> then we decided to make it into an alternative front-end, with the preview plot as the central feature
[18:33:34] <jepler> cradek drew the first "toolbar and tabs" style layout, and the rest is history
[18:37:12] <skunkworks> nice. I love it.
[18:37:52] <skunkworks> I just made a 12 pin plug out of a 16 pin. They seem to go togather really easy. (sanded it to length)
[18:38:20] <skunkworks> should probably glue it (the end that looses the clip)
[18:41:40] <skunkworks> or maybe not - the proccess of belt sanding it causes the plastic to melt togather. ;)
[18:42:22] <jepler> bonus
[18:57:46] <jepler> skunkworks: will you be using the index pulse feature?
[18:57:56] <jepler> I hear it's great for homing
[18:58:17] <jepler> cradek: oh, did you see that mdynac reports he had been using home-to-index-pulse? I think I remember you expressing that you weren't sure it ever worked
[18:58:27] <cradek> cool
[18:58:35] <cradek> he's using motenc I think
[18:59:55] <jepler> yep
[19:00:05] <skunkworks> jepler: it will be the plan.
[19:00:11] <jepler> we changed some of the pin names since 2.0, though, so his config didn't work in 2.1.
[19:00:19] <jepler> (or HEAD, I forget which he said he's using)
[19:00:34] <jepler> changes that weren't already noted on the UpdatingConfigs page
[19:00:40] <skunkworks> (if I understand it right - I will want to hit a limit switch - then home to the closest index pulse)
[19:00:44] <jepler> skunkworks: right
[19:01:08] <skunkworks> now i have a 24 pin ribbon cable.
[19:01:23] <skunkworks> 26 pin I mean
[19:01:52] <jepler> did you scavenge some headers yet?
[19:02:34] <skunkworks> ordered some.. Should be in today or tomorrow
[19:08:34] <jepler> I hope that whichever day the new plutos come I can finish testing the reset method and the index pulse with digital filtering
[19:08:52] <Lerneaen_Hydra> new pluto?
[19:09:01] <jepler> Lerneaen_Hydra: I killed the one I had
[19:09:20] <Lerneaen_Hydra> oh.. :(
[19:09:20] <Lerneaen_Hydra> how?
[19:09:22] <SWPadnos> jepler, do you have a plan for the filtering code?
[19:10:16] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/pluto.jpg
[19:10:17] <skunkworks> crappy picture
[19:10:21] <jepler> SWPadnos: I added a 3-bit register of the index input, and I'll only treat it as a real pulse when all 3 bits were 1
[19:10:46] <SWPadnos> a shift register or a counter?
[19:11:01] <jepler> SWPadnos: a shift register
[19:11:15] <SWPadnos> ok
[19:11:23] <SWPadnos> do you plan to allow for negative logic?
[19:11:36] <SWPadnos> (ie, it's only a pulse when all bits are 0)
[19:12:22] <jepler> SWPadnos: right now the index pulse polarity is fixed as active high
[19:12:25] <SWPadnos> ok
[19:13:34] <SWPadnos> there are a couple of other methods I've thought about, one uses a shift register approach and the other a counter with separate high and low thresholds
[19:15:28] <SWPadnos> the shift register approach uses both the ans and the or of all bits, and only changes output state when AND(all bits) == OR(all bits)
[19:15:34] <SWPadnos> s/ans/and./
[19:19:37] <SWPadnos> I wonder if it would be better for the parport configs to use write_all and read_all by default, so people can add ports and not worry about it
[19:58:22] <jepler> I guess it would have helped in this case
[19:59:17] <SWPadnos> the only downside is that it takes a few extra cycles for loop overhead
[19:59:24] <SWPadnos> I thnk
[19:59:26] <SWPadnos> think
[19:59:50] <jepler> some people with 2 ports might put the steppers on one and the stuff that can be read less frequently on the other
[20:00:13] <jepler> one in base_thread and one in servo_thread
[20:00:18] <SWPadnos> that's true
[22:24:27] <SWPadnos> that snippet of code was correct - you write a 1 or 0 to the encoder count address tu turn index latching on/off
[22:50:33] <alindeman> [Global Notice] Hi all. You're currently on a freenode server that's going to be restarted soon to upgrade the ircd code. This will happen at midnight GMT (a little over an hour from now). If you wish to reconnect to another server, feel free to reconnect to chat.freenode.net--none of the servers in that rotation will be affected. If you do not reconnect now, you can expect to be shunted from the server, but most clients will r
[22:52:41] <alindeman> [Global Notice] ... most clients will reconnect cleanly and the server should come back online immeadiately. Thanks for your cooperation and use of freenode!
[23:24:37] <skunkworks> logger_dev: bookmark
[23:24:37] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2006-12-05.txt
[23:47:58] <jepler> skunkworks: since I don't have a board to work on, I've pulled together some info about the pluto_servo and tried to make it into documentation. Let me know what is confusing, or what questions you have left after reading it:
http://emergent.unpy.net/files/sandbox/pluto_servo.html
[23:48:04] <jepler> I'll be back later
[23:49:22] <skunkworks> jepler: thanks - look at it tongiht
