#linuxcnc-devel | Logs for 2016-01-01

[08:13:05] <KGB-linuxcnc> 03John Thornton 052.7 8233e35 06linuxcnc 10docs/src/index_es.tmpl Docs: fix broken link * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8233e35
[08:50:12] <jthornton> don't think I'll get done with mb2hal docs this morning but got a good start...
[12:26:41] <jepler> http://idlewords.com/talks/website_obesity.htm
[12:38:33] <archivist> hehe and his page is 104 resources 1.01MB 988.9kB
[12:38:48] <archivist> good article though
[12:42:33] <KGB-linuxcnc> 03andypugh 052.7 03d2d11 06linuxcnc 10configs/sim/axis/vismach/VMC_toolchange/spindle.hal Connect the orient mode pin to allow rotation direction to be controlled in the VMC Vismach model * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=03d2d11
[12:53:13] <mozmck> I don't understand some things in the PID component. There is a command-deriv pin for velocity, (pid->commandv internally), and a pointer commadvds which is set to pid->commandv after creating the pin.
[12:54:31] <mozmck> This commandvds is set in calc_pid(): *(pid->commandvds) = (command - pid->prev_cmd) * periodrecip;
[12:56:20] <mozmck> ...if index_enable is not true. It seems like this will override the value in pid->commandv - which is an IN pin. Is that true? If so I guess the command-deriv input pin is not used unless index-enable is true.
[13:00:39] <andypugh> pid knows to ignore the last delta when the encoder resets. As far as I know that works.
[13:01:50] <andypugh> But what you might be seeing is some clever code that detects if a pin has been connected in HAL by roundabout means.
[13:05:18] <andypugh> The pid inputs are described here: http://sourceforge.net/p/emc/mailman/message/26498770/
[13:06:10] <andypugh> The way that the component detects if the inputs are “wired” is here: http://sourceforge.net/p/emc/mailman/message/26519176/
[13:06:24] <pcw_home> I know feedback-deriv works that way ( feedback velocity is calculated internally if not connected)
[13:07:13] <mozmck> Interesting. The code seems to look at the index-enable pin to know if it should calculate internally
[13:08:56] <andypugh> That seems odd, you would expect it to look at feedback-deriv
[13:09:56] <mozmck> if(!(pid->prev_ie && !*(pid->index_enable)))
[13:11:55] <andypugh> That looks to be saying “if index enable has not just gone fromtrue to false”
[13:11:56] <pcw_home> for command derivative I dont think there would be any difference between
[13:11:57] <pcw_home> DDT of position and the external joint velocity connected to command-deriv
[13:12:38] <andypugh> So, it’s refusing to calculate a new derivative if there is reason to belive that encoder position has changed.
[13:12:55] <andypugh> (step change, that is)
[13:12:58] <pcw_home> in any case you need to skip calculating the DDT on index-enable falling edge
[13:13:24] <mozmck> what is DDT?
[13:13:45] <mozmck> derivative of distance over time?
[13:13:55] <andypugh> discrete differential wrt time
[13:23:50] <pcw_home> arguably this ( dealing with position steps) should not be done in the PID component
[13:23:52] <pcw_home> ( if machine and encoder coordinates were kept separate, there would never be a step at the control loop level )
[13:23:53] <pcw_home> This would require smart encoder logic that does _not_ reset at index (HM2 encoders are like this, not sure about others)
[13:26:06] <andypugh> Yes, I rather agree. Certainly a PID component looking for index-enable seems too specialised.
[14:34:24] <andypugh> So, I am looking into what it takes to add spindle homing to the homing sequence. And it is one of those things that could be done quickly and dirtily in homing.c, or properly by inventing a new spindle_t to match the joint_t and an ini_spindle code in src/emc/ini to read the INI file, and then consider the future possibility of multiple spindles… and then it looks iike a big job.
[14:46:18] <mozmck> Does spindle homing refer to orienting the spindle?
[14:48:16] <andypugh> Yes. If the spindle encoder is quadrature then you need to turn it once to find the index before you can orient.
[14:50:01] <mozmck> So is that something that might be needed for a multi-spindle machine?
[14:50:30] <mozmck> What kind of spindle needs that anyhow? Lathe?
[14:50:36] <andypugh> I have no idea :-)
[14:50:59] <andypugh> But every time I assume that nobody will need anything, along comes someone needing it.
[14:51:05] <mozmck> Well, if it never gets used then the quick and dirty method should suffice :-)
[14:51:17] <andypugh> Which reminds me….
[14:57:11] <KGB-linuxcnc> 03andypugh 05master b2553ce 06linuxcnc 10src/hal/components/carousel.comp Astonishingly at least one manufacturer thought that BCD was a good way to encode a tool carousel * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b2553ce
[14:59:12] <pcw_home> BCD was very common on old instruments (60's and 70's)
[14:59:13] <pcw_home> Don't X86s have BCD instructions?
[14:59:56] <andypugh> The Z80 certainly has.
[15:00:32] <andypugh> But how many tool carousels need the second digit?
[15:01:18] <pcw_home> A _long_ time ago I made a thermocouple simulator from a TI SR52 calculator
[15:01:19] <pcw_home> I used the printer interface (which used nibble serial BCD) and a 4 digit BCD DAC
[15:01:29] <andypugh> You need 5 sense lines for 10 tools with BCD, whereas yoy can have 15 (or 16) with 4 sense lines and binary.
[15:01:54] <andypugh> A four digit carousel would be a think to see
[15:01:59] <pcw_home> Yeah decimal thinking
[15:02:59] <pcw_home> All this metric stuff has me wondering when they will metrify time
[15:03:25] <pcw_home> Tempits and millitempits
[15:03:47] <andypugh> 1 day = 1 megasecond? (for a smaller second)
[15:04:48] <andypugh> I saw a fairly sensible suggestion to have 13 months of 28 days. And for New Years Day to not belong to any month. (and to have two of them on a leap year)
[15:06:15] <seb_kuzminsky> andypugh, pcw_home: about the pid thing, motion has 'motor-pos-{cmd,fb}' as well as 'joint-', isn't motor-pos what you're looking for? it's unaffected by backlash and screw compensation and home offset
[15:08:48] <andypugh> I was just explaining why pid had index-enable to mozmck. I am not sure what else was being discussed
[15:10:19] <pcw_home> seb_kuzminsky, maybe... not sure what happens to motor-pos-fb when index is hit
[15:13:30] <pcw_home> maybe the split needs to be done at the encoder level (and motion is OK)
[15:17:08] <pcw_home> For example, the encoder comp (and all hardware encoder drivers I think) reset position on index so you have a step there
[15:19:49] <pcw_home> just saying these position steps are patched around in various places when it
[15:19:51] <pcw_home> should be possible to eliminate the steps at the control loop level though
[15:19:52] <pcw_home> this may be difficult with some encoder hardware that only has the option of clearing the count on index
[15:23:58] <mozmck> would there still be an index pulse?
[15:24:26] <pcw_home> sure
[15:25:04] <mozmck> I would think that could be used to keep track of the count internally then
[15:26:40] <pcw_home> To avoid all the PID/motion hacking around pos. fb and pos.cmd thumps the encoder component/driver
[15:26:42] <pcw_home> would have two position outputs one thats reset by index and one thats not
[15:27:30] <mozmck> why one that's reset by index?
[15:27:40] <pcw_home> but as I said this may not work with some encoder hardware thats hardwired to reset on index
[15:28:55] <pcw_home> thats the one that the joint position uses to get a accurate 0 on index (the motor pos fb is never "stepped")
[15:29:17] <pcw_home> just thinking out loud
[15:29:57] <mozmck> I guess I don't understand why the encoder driver can't just see the index pulse and see the 0 count as one more than 4096 (or whatever the max count is)
[15:30:33] <mozmck> I see. Your thinking helps me learn ;-)
[15:34:54] <pcw_home> Some encoder hardware can only reset the count on index (there's no way to avoid a position FB step with this)
[15:34:56] <pcw_home> the Hm2 encoder counter can reset on index or latch on index, with the latch on index option you can have a
[15:34:57] <pcw_home> stepless motor feedback position in addition the a position that was zeroed at the index event (by subtracting the latched offset at index)
[15:42:37] <mozmck> So for that hardware (no index pulse), maybe the driver can be told the max count so when it is on max count and the next goes back to 0 it knows it just moved one step forward.
[15:45:39] <pcw_home> You mean to simulate an index if you dont have one?
[15:46:33] <andypugh> mozmck: No help on the first index.
[15:48:51] <cradek> remember the first count you read after an index reset isn't necessarily 0 or 1, it can be 7 or 700, depending on how many counts you happen to be able to move in one servo cycle
[15:49:39] <cradek> your servo cycle readings might be 7000 9000 120[with index reset] 2120
[15:51:00] <cradek> the naive ddt would be ... 2000 -8880 (ouch) 2000 ...
[15:51:27] <cradek> with this current pid algorithm of skipping ddt calculations when index resets, you get ... 2000 2000[saved value from last time] 2000 ...
[15:51:34] <andypugh> What are we talking about again? The pid component sees float position feedback. Unless you tell the pid what the encoder scale is, it can’t see counts, raw or otherwise.
[15:52:15] <andypugh> The PID component could usefully reject step changes in feedback position when computing velocity, though.
[15:52:35] <cradek> yes, and it does
[15:52:49] <cradek> I thought that was the question (why does it care)
[15:53:02] <andypugh> So, it probably doen’t need to see the index enable then?
[15:53:20] <cradek> that's how it tells there was (potentially) a position step
[15:53:51] <andypugh> I am saying it could reject position steps based on their amplitude.
[15:54:21] <cradek> yes, if you want to make guesses, I bet you could often get it right
[15:54:28] <cradek> usually, even :-)
[15:54:49] <cradek> but in the homing situation we don't have to guess, and I think that's about the only time we get steps...?
[15:54:54] <andypugh> I don’t even know if you are agreeing with me or arguing with me
[15:56:13] <cradek> I agree with you that it's possible to throw out big steps in joint position on a real machine because you know some things are unreasonable
[15:57:05] <cradek> I'd argue if you said we should replace pid's algorithm with a heuristic, because pid currently doesn't guess and it gets it right even if the unwanted steps are small
[15:57:19] <andypugh> Yes, and that seems like a generic “PID”-ish thing to do. Looking at encoder index isn’t a “PID”-ish thing, it’s a LinuxCNC thing.
[15:58:41] <cradek> I agree, and the more generic the domain the less I'd feel confident saying what inputs are reasonable
[15:59:38] <andypugh> I am not suggesting that we change anything, it’s too late now, but passing the PID an unrelated LinuxCNC-only signal looks inelegant.
[16:00:09] <cradek> I agree it has a bit of a bad smell to it
[16:00:48] <cradek> the ignition coils in my car are failing one at a time. I wish I could remember how many are still original, and which ones they are
[16:01:19] <cradek> last time I bought two and kept a new one in the car - needed it today (a holiday of course)
[16:01:34] <seb_kuzminsky> cradek: i feel like you've taught me before why using motor-pos-cmd instead of joint-pos-cmd as the pid input is not an alternative to having pid see index-enable
[16:01:36] <andypugh> Rejecting any step bigger than maxerrorD would look like it was intentional, and I bet nobody has ever used that pin ;-)
[16:01:52] <seb_kuzminsky> but i dont remember the reason
[16:02:16] <mozmck> Oops, I stepped away - reading back...
[16:03:32] <pcw_home> My modest suggestion is that its the encoder comps/drivers problem (and if fixed there, no one else (motion, PID) need deal with it)
[16:05:00] <cradek> brb
[16:05:16] <pcw_home> the fly in that particular ointment is that it may not be easily fixable with encoder hardware that only has clear -on-index capability
[16:06:14] <mozmck> For a hardware encoder that resets on index, I'm assuming you mean there is no index pulse. When the encoder is first powered up and it is in the middle of a turn, does it know that? Or does it start counting from where it is?
[16:10:34] <pcw_home> No, I mean hardware that resets the raw position count on index
[16:12:06] <mozmck> By index pulse - I mean one that gets back to linuxcnc. If linuxcnc can see the index pulse then it can know that the count was just reset.
[16:13:55] <pcw_home> Typically this is done by either latching the count or reseting the count on index, and setting/clearing a
[16:13:57] <pcw_home> flag to indicate this has happened
[16:13:59] <andypugh> pcw_home: If such an encoder existed, would LinuxCNC actually see the index-enable go false?
[16:14:42] <pcw_home> yes, it needs this for homing and spindle synchronized moves
[16:15:09] <pcw_home> just sayin the position with the step need not be the one used for PID
[16:16:00] <andypugh> So, you set a hardware line high to request an index reset, then a separate hardware line is taken high to indicate that the encoder complied? It would be fune to interface that to a HAL bidirectional pin.
[16:17:00] <pcw_home> none of that need change
[16:17:23] <pcw_home> (though I really dont care for the bidirectional pin)
[16:18:52] <pcw_home> All I am saying is that there are a fair amount of workarounds for the step in position
[16:18:54] <pcw_home> feedback at index which might all be avoided by eliminating that step up stream
[16:23:36] <andypugh> Oh, I agree, but we are caught in the age-old problem, changing it now would break working machines.
[16:26:44] <pcw_home> Yeah, and the work-arounds do work...
[16:27:37] <seb_kuzminsky> i think it's ok to break working machines, on major releases (eg 2.6 -> 2.7), and with documentation (eg our "Updating your configs" section in "Upgrading LinuxCNC")
[16:27:55] <seb_kuzminsky> if it makes things better/simpler in the long run, i say bring it on
[16:28:13] <andypugh> It just makes things prettier in a layer users never see.
[16:28:48] <seb_kuzminsky> true
[16:29:01] <seb_kuzminsky> but it's a layer developers and integrators see, so it still has value
[16:29:08] <seb_kuzminsky> bbl
[17:09:42] <jepler> I got no negative feedback about the idea of transferring linuxcnc-mirror to the linuxcnc organization on github. I think we should go ahead and do it,
[17:09:53] <jepler> I think there was also a consensus to open the bugtracker there and close the sf tracker to new requests
[17:10:27] <jepler> .. as a further step, we should also install a hook on glo to update github immediately instead of with a hour delay
[17:10:31] <JT-Shop> sounds good to me
[17:11:41] <jepler> I think that as cradek is the creator of the linuxcnc github organization I'll need his time to do the transfer & rename step. so I've sent him a ping privately as well.
[17:14:23] <jepler> as far as encoder index goes, I think that there's a better design that would work for encoder with latch (like hostmot2) but I think that not all encoders have this. I think pico is an example of this type
[17:14:54] <jepler> so we do need room for both kinds of index, even if we find a way to integrate latch-based (rather than reset-based) index pulse to homing and threading
[17:15:32] <jepler> way back in the day, 24 bit floats meant that reset on index was good design so you didn't totally lose precision on your spindle -- you got back to best possible precision at the beginning of each thread
[17:18:11] <jepler> 24-bit-mantissa floats
[17:19:13] <archivist> reset on index seems to assume the encoder will keep the width within an amount, do ALL encoders do that
[17:20:08] <jepler> I'm not sure what you mean by "width".
[17:21:05] <archivist> number of edges from AB during the index
[17:22:01] <jepler> oh
[17:22:11] <pcw_home> not sure about other designs but the HM2 encoder latches or resets only once
[17:22:23] <jepler> so you mean, if you made your "Z" track half a rotation is it useless?
[17:23:28] <jepler> an index pulse that is "wide" in that way would still be useful for homing or threading as long as you consistently approach it from the same direction
[17:24:18] <jepler> but I think that in a traditional commercial encoder, the index pulse is narrow, 1 cycle or less of A or B
[17:24:20] <archivist> solid tapping is both directions, I hope the code is right :)
[17:24:38] <pcw_home> doesn't index detection clear index enable?
[17:24:51] <jepler> pcw_home: yes
[17:25:13] <pcw_home> so it will just detect the leading edge
[17:25:26] <jepler> yes
[17:25:43] <Roguish> hey, we're all obsolete now: http://build.slashdot.org/story/15/12/31/2212240/2016-is-the-year-of-buying-cnc-tools-instead-of-building-them
[17:26:44] <jepler> heh
[17:26:59] <archivist> clueless slashdotters
[17:27:09] <jepler> I'm primarily a software guy, so if my next toy to be driven by linuxcnc comes nearly assembled that's fine by me
[17:27:44] <jepler> some of my least favorite things include dealing with crimp tools and making nice permanent installations of circuit boards and cabling
[17:28:00] <archivist> I only build, I cannot buy in my price range usually
[17:30:59] <jepler> sounds sensible
[17:31:47] <jepler> I'm just buying AND building less than I once did
[17:32:29] <jepler> though 2015 may have been a record for *number of* complete linux computers purchased, it certainly was no where near the maximum dollars spent per year on linux computers
[17:32:32] <jepler> (for me)
[17:39:30] <andypugh> I rather like crimp tools. I have lots of them.
[17:39:57] <andypugh> I kike to have the right tool for every connector. I need to find one for the small-yellow pre-insulated size
[17:40:59] <jepler> it may be a case where I don't have good enough tools
[17:43:34] <andypugh> Well, I don’t spend lots, which is why I don’t have the small-yellow crimper. The only one I found was £400
[18:01:08] <jepler> the only way I'd own that expensive a crimper is by inheritance
[18:55:29] <jepler> > Moving repository to LinuxCNC/linuxcnc-mirror. This may take a few minutes.
[18:56:21] <jepler> sweet you can now clone https://github.com/LinuxCNC/linuxcnc
[18:57:06] <jepler> .. and github issues are now enabled
[19:03:55] <malcom2073> yay
[19:08:31] <KGB-linuxcnc> 03Jeff Epler 052.6 de59974 06linuxcnc 10docs/src/code/Contributing-to-LinuxCNC.txt docs: github is more official now * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=de59974
[19:08:52] <jepler> I have to go AFK, I hope I got that doc change right. I'll merge it up later unless someone jumps on the task.
[22:06:36] <KGB-linuxcnc> 03Jeff Epler 052.7 81d9a34 06linuxcnc 03docs/src/code/contributing-to-linuxcnc.txt Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=81d9a34
[22:08:36] <cradek> people start talking about motors and transformers and stuff, and jmk is all like "don't make me come over there" haha
[22:19:01] <seb_kuzminsky> i just moved the wlo (jekyll source for the www.linuxcnc.org website) to the github.com/LinuxCNC org
[22:20:18] <cradek> sweet
[22:20:39] <seb_kuzminsky> i should push to see if the website auto-updates
[22:21:58] <KGB-wlo> push to test-linuxcnc-org branch: http://wlo-test.highlab.com/test-linuxcnc-org
[22:22:12] <seb_kuzminsky> that was easy
[22:22:19] <seb_kuzminsky> the more i use github, the more i like it
[22:23:23] <andypugh> cradek: I get the feeling that Bertho knows his stuff too.
[22:23:35] <cradek> me too
[22:24:40] <seb_kuzminsky> i guess i could move the rtai/kernel repos to the LinuxCNC org too
[22:24:48] <cradek> I'm always amazed at how much variation there is around the world. when we're all chatting worldwide, it's hard to know what advice you can even use
[22:29:47] <andypugh> Yeah, even such things as what you can legally ground. I am pretty sure I am not allowed to bonf my neutral to earth anywhere but at the incoming supply.
[22:30:01] <andypugh> (bond)
[22:30:42] <andypugh> it comes down to what happens given two possible failures, I think.
[22:33:27] <jepler> cradek: the mirroring of linuxcnc amounts to me running this in cron:
[22:33:27] <jepler> cd /store/src/linuxcnc.git; git fetch --prune origin && git push --prune --mirror github
[22:33:36] <jepler> linuxcnc.git is a bare mirror of the real linuxcnc.git
[22:34:12] <jepler> so I think you just need to configure a github remote in the real linuxcnc.git which can "git push --prune --mirror github". You should be able to register a ssh key on github just for this purpose.
[22:34:30] <seb_kuzminsky> jepler: "git fetch --prune --tags origin"
[22:34:40] <jepler> seb_kuzminsky: ooh thanks
[22:35:33] <jepler> cradek: anyway let me know if you do this, or if you decide it is ill-conceived to do this; I'll either stop running my script, or start running it somewhat more often.
[22:35:41] <jepler> 'night all
[22:37:06] <seb_kuzminsky> night
[22:38:18] <cradek> I wonder if that could go in post-receive instead of cron
[22:38:37] <cradek> or some appropriate hook anyway
[22:40:25] <jepler> cradek: right, doing it from a hook would make it nearly instant
[22:40:38] <jepler> I guess I wasn't entirely clear that's what I was asking for
[22:41:29] <cradek> I will try to do this tomorrow
[22:41:38] <jepler> excellent news
[23:23:08] <KGB-linuxcnc> 03chris morley 05panelui 9026057 06linuxcnc 10src/hal/components/panelui.c panelui: only use one channel of sampler input * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9026057