Back
[07:23:44] <skunkworks> and it looks like you cannot remap M5? how much work is that I wonder.
[07:43:47] <skunkworks> I see it disapear if you add a small g0 move before the m5. the move could be really small .0001
[07:46:10] <skunkworks> I could see (maybe - I have not used remap..) check mm/metric (or maybe you wouldn't have to as the move either way could be really small) check rel/abs - switch to rel - move small amount - m5 - switch back to previous rel/abs
[07:56:29] <skunkworks_> http://imgur.com/30rgU3T
[07:57:43] <skunkworks> interesting observation.. why does program line dip to zero in the middle?
[07:59:19] <skunkworks> Hmm - skips over non moves?
[07:59:26] <skunkworks> maybe I never noticed that
[08:00:16] <micges> skip over non moves
[08:00:41] <skunkworks> must have never noticed that :)
[08:01:53] <micges> it's not visible in axis gui, but if you create progress bar it's visible
[08:07:35] <skunkworks_> this is the minimum x.0000001
[08:07:48] <skunkworks_> any less than that and it must get filtered out
[08:07:53] <skunkworks_> Inch
[08:08:26] <micges> skunkworks_: what problem with m5 does mozmck have?
[08:10:17] <skunkworks_> if you don't add an extra g0 move at the end of the segments before the m5 - you get a dip in velocity
[08:11:16] <micges> new tp?
[08:13:39] <skunkworks_> http://pasteboard.co/zzTUBUc.png
[08:13:45] <skunkworks_> compared to mine above.
[08:14:33] <skunkworks_> yes - if you read back - rob had emailed me with an explaination. something to do with no knowing if a segment is the last segment or such. I don't understand it very well
[08:15:34] <micges> can you try adding g4 p0.01 between g1 and m5?
[08:17:14] <skunkworks> nope
[08:17:39] <skunkworks> (I mean - it didn't help_ M5 should have the same effect as G4 in that situation
[08:18:16] <micges> I see
[08:19:07] <skunkworks> I think what is happening is the tp is falling back to parabolic blending for the last segment because it doesn't know what is coming next.
[08:19:22] <skunkworks> My thought anyway
[09:11:34] <mozmck> skunkworks: so Rob actually emailed you back with that?
[09:12:50] <mozmck> micges: here is my bug report:
https://sourceforge.net/p/emc/bugs/437/
[09:13:04] <micges> thanks
[09:13:54] <skunkworks> yes
[09:14:08] <mozmck> I verified last night that M62/M63 have the same behavior
[09:14:47] <skunkworks> It isn't the M62/M63 it has to do with the last segment. as I understand it.
[09:16:03] <mozmck> Well, it is a combination, because there is no glitch if there is no M62/63/67 before the last segment
[09:16:05] <skunkworks_> mozmck: maybe a work around?
[09:16:07] <skunkworks_> http://pastie.org/10429136
[09:16:38] <skunkworks> I didn't actually try re-mapping M5 but according to the documents it isn't possible
[09:16:47] <skunkworks> (I am using m55)
[09:17:14] <mozmck> skunkworks: I thought of that - and I guess a nasty hack like that might work if we get really desperate.
[09:17:53] <mozmck> The interesting thing is that a larger move does not help the problem
[09:18:51] <micges> mozmck: what does M67 E0 Q20 do?
[09:20:37] <mozmck> It sets an analog hal pin which a custom HAL component reads and uses to control variables in our THC
[09:21:44] <skunkworks> mozmck> Well, it is a combination, because there is no glitch if there is no M62/63/67 before the last segment
[09:22:28] <skunkworks> that is because adding M62/3/7 trumps the ncd. (it can't combine the segments)
[09:23:11] <skunkworks> IF you removed the M62/3/7 and set Q0 in g64 - you would see the same thing
[09:25:09] <skunkworks> (just trying to explain it for myself also)
[09:27:33] <mozmck> Whatever the reason, it sounds like a bug to me. It will also affect people using M62/M63 for laser control.
[09:27:55] <pcw_home> wonder if its a terrible idea to apply things like M67 as tags in commanded position stream
[09:29:31] <mozmck> pcw_home: you mean internally?
[09:30:38] <pcw_home> a bad idea but you could do something like this in HAL
[09:32:22] <pcw_home> but I guess the current issue is that m67 is a queue buster but should not really have any side effects
[09:34:18] <pcw_home> is this just a bug with M67 and NCD?
[09:38:45] <skunkworks> this is what rob replied
[09:38:46] <skunkworks> I think what's happening is that NCD is combining segments together if there is no M67, but it can't do that if there is. If you make Q 0.0, the effect disappears (in that you see the blip regardless).
[09:38:46] <skunkworks> It's the age-old problem of telling the motion side that the program is done, or that we've hit a queue buster and to assume that the last segment will be exact stop. Since there isn't a clean way to do this now, the workaround is to have a lead-out move of some sort (for example, a rapid down to the work and back up after the cut). If the last segment is not cutting, then the little blip won't affect the part.
[09:39:44] <skunkworks> I asked him about what to do in the future and he posted
[09:39:47] <skunkworks> I looked into that before, and I'm not sure there's a good answer. We effectively need a way to tell motion to do an exact stop at the end of the queue. One way might be a special motion command that says that we're done sending moves for now (i.e. queue buster or end-of-program). Then, we could override the stop condition of the last move (make it exact stop), and re-run the optimization to remove the blip. The PIT
[09:39:47] <skunkworks> A part is making sure that all the queue buster commands actually trigger this command, and implementing all the NML plumbing to pass it along.
[09:42:12] <pcw_home> thats sort of what i was getting at, the M67 could be made to work
[09:42:14] <pcw_home> even with NCD if the M67 was deferred to the interpolator
[09:43:44] <pcw_home> maybe m88 X 3.45
[09:47:12] <skunkworks> I see - your telling it where you want it to trigger
[09:59:05] <mozmck> what is M88?
[10:02:54] <skunkworks> I think he is just giving an example of a new M code. (where you tell it where you want the dio to switch)
[10:03:04] <skunkworks> or aio
[10:07:03] <mozmck> That's what M62/63/67 are supposed to do
[10:07:56] <skunkworks> mozmck, what effect does that dip have on the part?
[10:08:54] <mozmck> If it's bad enough, it creates a divot
[10:11:29] <mozmck> We can do without the M67 much of the time it looks like for now as a workaround. If there is a way to do it with another M code that would work too.
[10:12:26] <skunkworks> mozmck, sorry I never notice that in testing..
[10:13:19] <mozmck> heh, not your fault - thanks for helping!
[11:50:10] <kwallace> An example of 1914 technology:
http://ninanet.net/watches/others13/Mediums/mpatekpw.html
[11:55:07] <malcom2073> Every once in a while I hear someone say "I wish I could travel back in time, I'd be so smart compared to them!". People have been freaking amazing forever, just the venue has changed
[11:56:27] <cradek> the tips of the escape wheel teeth and the wolfs-tooth winding wheels are neat
[11:57:10] <cradek> the escape wheel is strangely unfinshed, otherwise
[11:57:21] <cradek> replacement maybe
[13:49:49] <mozmck> Why would you want a text editor written in Javascript that reports to Google?
https://github.com/atom/metrics
[13:50:36] <pcw_home> because all of your base belongs to google
[14:11:15] <jepler> cradek: can linuxcnc do "floppy homing" without wiring up some sort of fake home switch input?
[14:11:39] <cradek> no way I know of
[14:12:46] <skunkworks> floppy homing?
[14:13:45] <mozmck> Does rob ellenburg have a github repo?
[14:14:16] <jepler> skunkworks: where you just bash into the end-stop of the travel on purpose
[14:14:23] <jepler> works great for finding track 0 on a floppy disk
[14:15:06] <skunkworks> ah - ok. funny
[14:15:24] <skunkworks> mozmck,
https://github.com/robEllenberg/linuxcnc-mirror
[14:16:00] <mozmck> Can't you just set your HOME_VEL to 0, jog to stop and click to home the axis?
[14:16:16] <jepler> sure I could do it manually
[14:16:44] <skunkworks> I was thinking some sort of hal timer that just waited a few minutes then tripped all the home pins.
[14:16:54] <skunkworks> (while homing)
[14:17:02] <mozmck> crash detector
[14:17:30] <mozmck> thanks for the link skunkworks - I was not finding it using the search on github.
[14:17:41] <skunkworks> or however long it takes the longest axis to go from one end to the other...
[14:17:55] <skunkworks> cradek had the same issue recently
[14:21:01] <skunkworks> Google finds it though ;)
[14:21:35] <mozmck> I guess I should use that instead. Seems like the github search is not great.
[14:21:45] <cradek> that's very polite of you
[14:21:45] <PCW> some simple servo systems home detecting the motor stall
[14:21:57] <PCW> home by
[14:27:09] <skunkworks> https://www.youtube.com/watch?v=Z2gBYIqDuYY
[14:35:00] <PCW> thats neat
[14:37:07] <Tom_itx> yep, i'm watching the pulley one that came up after it
[14:37:15] <Tom_itx> timing pulley
[14:57:53] <jepler> I ordered one of those sub-$100 "300mW" laser engravers and it came today. It does produce a discernable line on thin cardboard at 512mm/min and a dark line at 64mm/min. Once I get tired of using the GRBL controller I'll desolder it (boo, it's not socketed like it I had hoped) and hook it up to linuxcnc via a mesa card.
[14:59:14] <jepler> it uses what look like linear motion assemblies ripped out of 3.5" drives which is the reason for the speculation about homing
[14:59:52] <jepler> https://goo.gl/photos/vc227yv9drXZaUsT7
[15:03:20] <jepler> cradek quickly spotted how shoddy the heatsink attachment is -- contact between the laser diode assembly and the heatsink is on one line and two points (setscrews that when loose let you adjust the laser focus)
[15:16:56] <skunkworks> how do you like grbl?
[15:18:02] <skunkworks> wow - that really is disk drive assemblies
[15:19:29] <skunkworks> mount the laser on your other machine.
[15:32:12] <jepler> skunksleep: eh I haven't done anything "real" with it yet
[15:33:22] <jepler> it supports g0, g1, x, y, z, g4p, m3, and m5 so all that is good
[15:35:34] <jepler> cradek: is truetype-tracer-4.0 current?
[15:39:26] <cradek> the linuxcnc repo has 4.1-2
[15:39:30] <jepler> ah hm
[15:41:36] <cradek> git://timeguy.com/truetype-tracer.git
[15:45:22] <jepler> hm not quick to make that use grbl-style gcode. no arithmetic in it.
[15:46:12] <cradek> is there arithmetic? I thought the splines would be the problem.
[15:46:24] <jepler> yes, scaling
[15:46:25] <jepler> /G00 X [1330*#3+#5] Y [2816*#3+#6] (moveto)
[15:46:35] <cradek> huh
[15:47:11] <cradek> good reason to write the gcode2gcode you've always wanted to write
[15:47:20] <jepler> ugh
[15:47:39] <cradek> you could hack sai in 5 minutes to do it adequately
[15:53:28] <jepler> yeah
[16:34:27] <jepler> it took more than 5, and I used gcodemodule and not sai
[21:43:11] <skunkworks> jepler:
http://www.cnczone.com/forums/opensource-software/271966-grbl-logging-linuxcnc.html
[21:43:25] <skunkworks> I was able to talk to the developer
[22:00:34] <jepler> hmph can't see the images without signing in
[22:01:15] <jepler> oh well
[22:10:49] <jepler> so far it looks like the 9600 baud serial connection is a limiting factor when trying to do a halftoned image
[22:12:10] <jepler> one pixel consisting of Xnn.nn\nM3\nXnn.nn\nM5, 19 characters; you only get about 50 of those in a second
[22:12:28] <jepler> worse because I think my sending program is a very naive one and waits for acknowledgement of each sent line
