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?
Still moved to Wichita?
KimK: it's been on the mailing lists, let me find you a url
[01:04:42] <jepler> http://firstname.lastname@example.org
Oh, the mailing lists. I've got to sign up for that one of these days.
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
cradek: what is the reason that G10 L1 couldn't set front angle and back angle of tool ?
never mind I fingered it out I needed to use the ctrl_type=v,v
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/tutorial.lyx: removing freqgen, more to do yet
damn - BigJohnT - you're a doc demon
Thanks again for all your work
micges_emc: only because there was no standard to follow for that, and I didn't think it was important.
patches thoughtfully considered
a quick check of the build bot and I didn't break anything so I'm off to work
cradek: I see
does g64pn work with m62/63?
and the naive cam detector
I think your going to have to tell him to use z.. I don't think this was thought about.
the naive cam detector won't modify a sequence g1 / m62 / g1
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
at least, it shouldn't
if it does, it's a bug
yep - that could be an M107, which might wait for a satellite connection or something
umm - that was odd.. ;)
(you should be used to it by now ;) )
how do you use z?
use a comparator Z>0 and use that to run the lazor
ok, thanks cradek
hmmm. actually that should work well for the cases where people have a lot of short segments
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)
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)
I think these people who want to do laser scanning or whatever it is need an entirely different controller
one of them should man up and write it
yes they do
yeah, a raster controller is closer to freqgen+halstreamer than the current planner
would it work if all the off/on moves are short and the same length?
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
it may be simpler than that actually
* BJT-Work listens
since most raster engraving is done from an image
you have the pixel data already, and that's what you need to shift out to the laser PWM
the only thing that changes is how long each "pixel" should be active
and the stepover of course (which should be the same number)
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
easy for you to do :)
at the moment, I don't think that's so easy to do
easy for me to think about anyway ;)
a change to halstreamer, and/or a separate component that outputs clock pulses could help with the problem
(unless halstreamer already has the ability to change the sample output rate independent of the thread period it's run in)
* BJT-Work wanders off to make small bits from big chunks
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.
* you would have to have the z movement with the x movement.
but that is just a guess
coordinated motion makes straight lines, so you do know exactly when it will turn on
if you did a 0.002" move in X or Y and Z for off and on ...
from x-1z-.001 to x1z.001 it will turn on at x=0
ok - so you do know exactly when it will turn on. :)
so you would just have to setup your converter to make the on and off at each short line segment midpoint.
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.
but it might be slower than you want, depending on your vel/acc settings
there's currently no great solution IMO
but the naive cam detector won't work with it, since it will collapse all the little moves into one big one
yecky - oh well - glad I don't need this.... yet.
if he can up his accelleration a ton - it will work a lot better.
I bet you are right
how about me writing about a "laser component" in the manual then you guys make it... I'll be ahead of the curve then :)
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? :)
ok, that sounds easy to write about
don't forget all the options for image type, pixel size, and color -> laser intensity mapping
that should be automagical
well, you still have to tell the user that they don't have to worry about it
and describe how the magic works, so they feel better about it
NOTES: Do not program F commands with minus numerals, otherwise correct operation is not guaranteed.
hmm.. one idea I would try is making a component that acts like a lookup table
feed an "image" from userspace to it
then hook X&Y positions to it
along with a "enable" maybe from spindle-on
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.
(that would be neat)
it looks at current XY positions, and if the image has a nonzero value, output a laser on
then the g-code is simply enable the laser, and start the raster
and the component triggers the laser
(wonder if servo-thread would be ok for this, probably so)
alex_joni, that's a reasonable solution, but I would be concerned about the amount of data needed for it
depends on the resolution ;)
an image could be megabytes, and the data has to be in (kernel) memory since the component would need to be RT
still.. megabytes are cheap today
servo thread could be OK, and that's the resolution available with M6xx anyway
installing another DIMM in the machine, sure beats rewriting half of emc2
oh, it's not a question of total system RAM, it's more the idea that lots of data gets loaded into kernel space
also, you'd have to run EMC every time you change the image ;)
(unless you also have a usersoace helper that can reload the image and limits/resolution data)
something like hal_streamer
to feed the data
somewhere I had a proposal to make halsampler/halstreamer "clockable"
I don't think I ever wrote the code, though
EMC: 03tissf 07TRUNK * 10emc2/docs/src/hal/tutorial_fr.lyx: french translation update - attempt to follow John