Back
[00:56:52] <KimK> jepler or cradek, Re: "I think we've decided to travel on thursday the 21st and thursday the 28th", Is this for the CNC Workshop? Are you talking May or June? Has an announcement been posted?
[00:57:44] <KimK> Still moved to Wichita?
[01:03:52] <jepler> KimK: it's been on the mailing lists, let me find you a url
[01:04:42] <jepler> http://mid.gmane.org/[email protected]
[01:04:53] <KimK> Oh, the mailing lists. I've got to sign up for that one of these days.
[01:04:58] <KimK> Thanks!
[11:13:18] <BigJohnT> anyone around?
[11:15:30] <BigJohnT> I'm working on the HAL tutorial and I'm stuck on what to change net X_vel => freqgen.0.velocity to in the example
[11:15:32] <BigJohnT> http://www.linuxcnc.org/docview/devel/html//hal_tutorial.html#r1_5_2
[11:55:18] <micges_emc> cradek: what is the reason that G10 L1 couldn't set front angle and back angle of tool ?
[12:04:47] <BigJohnT> never mind I fingered it out I needed to use the ctrl_type=v,v
[12:26:27] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/tutorial.lyx: removing freqgen, more to do yet
[12:27:18] <skunkworks> damn - BigJohnT - you're a doc demon
[12:27:37] <skunkworks> Thanks again for all your work
[12:59:15] <cradek> micges_emc: only because there was no standard to follow for that, and I didn't think it was important.
[12:59:36] <cradek> patches thoughtfully considered
[13:00:54] <BigJohnT> a quick check of the build bot and I didn't break anything so I'm off to work
[13:02:05] <micges_emc> cradek: I see
[13:33:48] <BJT-Work> does g64pn work with m62/63?
[13:34:12] <BJT-Work> and the naive cam detector
[13:36:43] <skunkworks> I think your going to have to tell him to use z.. I don't think this was thought about.
[13:37:03] <jepler> the naive cam detector won't modify a sequence g1 / m62 / g1
[13:37:08] <SWPadnos> I think the outputs change when next_segment_vel >= this_segment_vel
[13:37:18] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=75822
[13:37:20] <jepler> at least, it shouldn't
[13:37:24] <jepler> if it does, it's a bug
[13:37:53] <SWPadnos> yep - that could be an M107, which might wait for a satellite connection or something
[13:38:24] <skunkworks> umm - that was odd.. ;)
[13:39:01] <SWPadnos> which?
[13:39:07] <SWPadnos> (you should be used to it by now ;) )
[13:41:08] <skunkworks> ;)
[14:06:43] <BJT-Work> how do you use z?
[14:12:48] <cradek> use a comparator Z>0 and use that to run the lazor
[14:13:14] <BJT-Work> ok, thanks cradek
[14:13:34] <SWPadnos> hmmm. actually that should work well for the cases where people have a lot of short segments
[14:14:08] <jepler> one problem with that is getting the on-to-off transition to take place when desired. another is that it still suffers with short segments, and turning on tolerance mode is sure to break it (since you'll use very small z moves to indicate laser state)
[14:14:21] <SWPadnos> for longer segments it's not as good, since Z will change gradually over the move (thus changing the laser state midway through the move or thereabouts)
[14:14:22] <jepler> I think these people who want to do laser scanning or whatever it is need an entirely different controller
[14:14:32] <jepler> one of them should man up and write it
[14:14:33] <cradek> yes they do
[14:15:08] <SWPadnos> yeah, a raster controller is closer to freqgen+halstreamer than the current planner
[14:17:40] <BJT-Work> would it work if all the off/on moves are short and the same length?
[14:17:42] <cradek> you "just" need to queue up an arbitrary number of on/offs that should happen during the scanline, and then the tp would twiddle the bit as the move progresses
[14:18:07] <SWPadnos> it may be simpler than that actually
[14:18:19] <BJT-Work> * BJT-Work listens
[14:18:27] <SWPadnos> since most raster engraving is done from an image
[14:18:43] <SWPadnos> you have the pixel data already, and that's what you need to shift out to the laser PWM
[14:18:55] <SWPadnos> the only thing that changes is how long each "pixel" should be active
[14:19:03] <SWPadnos> and the stepover of course (which should be the same number)
[14:19:46] <SWPadnos> so you run the laser head at a fixed rate, and you shift the pixel data out at whatever rate is needed to get the pixels to be the right width
[14:20:07] <BJT-Work> easy for you to do :)
[14:20:09] <SWPadnos> at the moment, I don't think that's so easy to do
[14:20:11] <SWPadnos> heh
[14:20:15] <BJT-Work> heh
[14:20:17] <SWPadnos> easy for me to think about anyway ;)
[14:21:22] <SWPadnos> a change to halstreamer, and/or a separate component that outputs clock pulses could help with the problem
[14:22:01] <SWPadnos> (unless halstreamer already has the ability to change the sample output rate independent of the thread period it's run in)
[14:24:54] <BJT-Work> * BJT-Work wanders off to make small bits from big chunks
[14:32:28] <skunkworks> you would have the z movement with the z movement - as jepler said - you then don't know exactly when the laser will turn on. although - for changing the laser power during the scan would work great.
[14:32:44] <skunkworks> * you would have to have the z movement with the x movement.
[14:33:04] <skunkworks> but that is just a guess
[14:33:28] <cradek> coordinated motion makes straight lines, so you do know exactly when it will turn on
[14:33:56] <BJT-Work> if you did a 0.002" move in X or Y and Z for off and on ...
[14:34:12] <cradek> from x-1z-.001 to x1z.001 it will turn on at x=0
[14:34:35] <skunkworks> ok - so you do know exactly when it will turn on. :)
[14:35:34] <skunkworks> so you would just have to setup your converter to make the on and off at each short line segment midpoint.
[14:38:00] <cradek> one move for every "pixel" with the endpoints being the middle of the "pixels" would give you constant speed. if the Z component is very small it won't affect the speed.
[14:38:20] <cradek> but it might be slower than you want, depending on your vel/acc settings
[14:38:40] <cradek> there's currently no great solution IMO
[14:39:07] <SWPadnos> but the naive cam detector won't work with it, since it will collapse all the little moves into one big one
[14:39:14] <cradek> right
[14:41:42] <skunkworks> yecky - oh well - glad I don't need this.... yet.
[14:42:18] <skunkworks> if he can up his accelleration a ton - it will work a lot better.
[14:42:30] <skunkworks> as is
[14:43:32] <skunkworks> (with m63/63)
[14:44:49] <cradek> I bet you are right
[14:47:24] <BJT-Work> how about me writing about a "laser component" in the manual then you guys make it... I'll be ahead of the curve then :)
[14:54:30] <SWPadnos> how about adding a code, G1001, that takes a velocity and an image file name, and then outputs a raster from one line of the image? :)
[14:57:24] <BJT-Work> ok, that sounds easy to write about
[14:57:38] <SWPadnos> heh
[14:58:08] <SWPadnos> don't forget all the options for image type, pixel size, and color -> laser intensity mapping
[14:58:25] <BJT-Work> that should be automagical
[14:58:48] <SWPadnos> well, you still have to tell the user that they don't have to worry about it
[14:58:59] <SWPadnos> and describe how the magic works, so they feel better about it
[14:59:09] <BJT-Work> heh
[18:59:41] <cradek> NOTES: Do not program F commands with minus numerals, otherwise correct operation is not guaranteed.
[19:01:36] <SWPadnos> heh
[19:08:56] <alex_joni> hmm.. one idea I would try is making a component that acts like a lookup table
[19:09:06] <alex_joni> feed an "image" from userspace to it
[19:09:18] <alex_joni> then hook X&Y positions to it
[19:09:26] <alex_joni> along with a "enable" maybe from spindle-on
[19:09:36] <cradek> G17 G02(G03) I... J... F... Ln; With this command, complete circular interpolations are repeated n times. Without an L designation, the interpolation is executed only once.
[19:09:52] <cradek> (that would be neat)
[19:10:00] <alex_joni> it looks at current XY positions, and if the image has a nonzero value, output a laser on
[19:10:26] <alex_joni> then the g-code is simply enable the laser, and start the raster
[19:10:33] <alex_joni> and the component triggers the laser
[19:10:48] <alex_joni> (wonder if servo-thread would be ok for this, probably so)
[19:11:02] <SWPadnos> alex_joni, that's a reasonable solution, but I would be concerned about the amount of data needed for it
[19:11:22] <alex_joni> depends on the resolution ;)
[19:11:26] <SWPadnos> an image could be megabytes, and the data has to be in (kernel) memory since the component would need to be RT
[19:11:28] <SWPadnos> he
[19:11:30] <SWPadnos> h
[19:11:40] <alex_joni> still.. megabytes are cheap today
[19:11:47] <SWPadnos> servo thread could be OK, and that's the resolution available with M6xx anyway
[19:11:52] <alex_joni> yup
[19:12:24] <alex_joni> installing another DIMM in the machine, sure beats rewriting half of emc2
[19:13:15] <SWPadnos> oh, it's not a question of total system RAM, it's more the idea that lots of data gets loaded into kernel space
[19:13:26] <SWPadnos> also, you'd have to run EMC every time you change the image ;)
[19:13:46] <SWPadnos> (unless you also have a usersoace helper that can reload the image and limits/resolution data)
[19:13:52] <SWPadnos> space
[19:16:09] <alex_joni> something like hal_streamer
[19:16:12] <alex_joni> to feed the data
[19:16:59] <jepler> somewhere I had a proposal to make halsampler/halstreamer "clockable"
[19:17:11] <jepler> I don't think I ever wrote the code, though
[20:45:24] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/docs/src/hal/tutorial_fr.lyx: french translation update - attempt to follow John