Back
[00:29:08] <skunkworks> ha
[00:29:12] <skunkworks> ah even
[00:45:09] <jepler> cradek: oh, is the low feedrate important?
[00:45:10] <jepler> I was so bored
[00:46:56] <jepler> thanks for finding and fixing
[00:49:27] <jepler> though I would have sworn I watched the first pass of the program..
[00:50:04] <jepler> thank heavens, that other commit I mentioned is something I've rashly backported to 2.3 as a performance fix
[04:19:24] <SWPadnos> man. I really wish I had taken the time to write the "pyvcp panel generator" I started on
[04:19:45] <mozmck> you need it now?
[04:19:48] <SWPadnos> to generate a panel for all pins that match a given pattern
[04:20:05] <SWPadnos> well, it would help with jimbo655 I think
[04:20:26] <SWPadnos> generate a m5i20.0.*din* panel
[04:20:42] <SWPadnos> so you'd get a bunch of LEDs that would be connected to all the inputs
[04:20:54] <SWPadnos> twiddle switches and you can see which inputs change
[04:20:58] <mozmck> yeah, some diagnostic panels could be handy.
[04:21:18] <SWPadnos> I guess that would be doable with a generic LED array panel and some shell scripts
[04:21:58] <SWPadnos> for a in `halcmd -s show pin $PATTERN` ...
[04:22:21] <jmkasunich> all he needs to do is read the halcmd output, it isn't that hard
[04:22:51] <SWPadnos> it's easier to look at a panel of LEDs to see which one toggles
[04:23:01] <SWPadnos> or halscope or a bunch of halmeters
[04:23:33] <mozmck> I was doing that tonight with the Hal Configuration window
[04:24:29] <mozmck> you click on the watch tab I think? and select a pin and it puts an led up for it
[04:24:31] <SWPadnos> p
[04:24:39] <SWPadnos> yep
[04:24:51] <SWPadnos> I think that may update slowly or something
[04:25:11] <mozmck> could be.
[04:25:41] <mozmck> but it showed me that my multiplexed input was working when I shorted the switch...
[04:25:53] <mozmck> the led blinked on and off...
[04:26:23] <mozmck> night...
[04:26:36] <SWPadnos> see you
[09:19:07] <micges> alex_joni: around?
[10:11:18] <CIA-1> EMC: 03micges 07master * r86253a297b84 10/src/emc/rs274ngc/ (interp_array.cc interp_check.cc interp_convert.cc): Add M67/M68 Enn Qnn - set analog output
[10:11:29] <CIA-1> EMC: 03micges 07master * rf1bd83105044 10/src/emc/task/emctaskmain.cc: Reenable code to check time spent in main task loop
[12:10:29] <CIA-1> EMC: 03micges 07master * r9c0e8f4c1a6f 10/src/emc/rs274ngc/ (interp_check.cc rs274ngc_return.hh): Improve P-word error detection and message
[12:10:30] <CIA-1> EMC: 03micges 07master * r2a8a98616eec 10/src/emc/rs274ngc/ (interp_check.cc rs274ngc_return.hh): Cleanup and update interp_check error messages
[13:03:37] <CIA-1> EMC: 03jepler 07master * r7058bc071cbd 10/ (4 files in 2 dirs): add a spindle speed output which is in revolutions per second
[13:16:01] <BJT-Hardy> micges: on M67/68 how many outputs do you have?
[13:18:58] <micges> as many as analog inputs
[13:19:05] <micges> default 4
[13:19:59] <BigJohnT> ok
[13:20:23] <BigJohnT> M67 is sync with motion like m62?
[13:20:55] <BigJohnT> and M68 is like M64 turn on immediately?
[13:21:25] <micges> exactly, (M67 will be, I'm writing code for this now :))
[13:22:01] <BigJohnT> I saw your commit so I was trying to update the manual :)
[13:22:26] <BigJohnT> Q is a float?
[13:22:32] <micges> BigJohnT: imo to early for this commit
[13:22:47] <BigJohnT> ok, I'll wait
[13:23:04] <micges> there is no G5.2 G5.3 entry of manual
[13:23:20] <micges> err gcode manual
[13:24:08] <BigJohnT> what is it?
[13:24:58] <BigJohnT> be back in a bit breakfast time
[13:25:07] <micges> some high level NURBS gcode , ask cradek e will be know all info
[13:25:22] <micges> he*
[13:30:36] <micges> bbl
[13:43:15] <cradek> I don't know much about it, but I have this file:
http://timeguy.com/cradek-files/emc/Leto_art837759.pdf
[13:43:20] <cradek> it has some documentation, but not all
[13:44:48] <BJT-Hardy> thanks cradek
[13:45:25] <cradek> EBo is our expert in the nurbs code
[13:46:02] <BJT-Hardy> YEA! you can cut and paste into lyx 1.5.3 with the keyboard
[13:46:27] <cradek> (the testing jeff and I did makes us think the nurbs code is not working right)
[13:46:53] <cradek> we did not spend much time on it.
[13:46:57] <BJT-Hardy> should I wait to add it to the manual?
[13:47:23] <cradek> well part of why we couldn't test it is because we weren't sure how it works
[13:47:37] <BJT-Hardy> :)
[13:47:44] <cradek> I don't know what to recommend.
[13:47:52] <cradek> if it is not documented, surely nobody will ever use it
[13:48:11] <cradek> if nobody ever uses it, it will not get fixed
[13:48:25] <cradek> but, if we don't have a maintainer, it probably won't get fixed no matter what
[13:48:49] <BJT-Hardy> I can add that it is experimental
[13:48:50] <cradek> and if that's the case, maybe it should be left undocumented or even removed.
[13:48:57] <cradek> ok that sounds smart
[14:04:26] <alex_joni> micges: one thing I'm thinking about (albeit not very much) is making the digital and analog inputs/outputs to belong to different modal groups
[14:04:33] <alex_joni> that way you can have both on the same line
[14:04:40] <alex_joni> but if they all use Pxx then forget it ;)
[14:36:54] <micges> alex_joni: cool idea
[14:37:32] <alex_joni> micges: it can be needed sometimes
[14:37:50] <alex_joni> set an analog voltage, then set a DO to trigger something that works based on the voltage
[14:39:47] <micges> I have M68 En Qn so it is possible
[14:41:02] <micges> alex_joni: question I would like to ask is: why M66 have timeout defined in whole seconds not ms like everything else? (I problABLY asked this already)
[14:41:24] <alex_joni> micges: I looked at G4 I think
[14:42:09] <alex_joni> I don't remember any g-codes that work in msec ..
[14:43:32] <micges> sorry. I mean I can G4 P0.2 and it will be wait 0.200ms, but when I M66 Q0.2 then will be no wat
[14:43:35] <micges> wait*
[14:44:04] <micges> even in message sended from canon timeout is integer field
[14:44:05] <alex_joni> hmm.. then it probably should :)
[14:52:32] <mozmck> BigJohnT: Dallur said you are rewriting the thc stuff as a component?
[14:53:15] <BigJohnT> yes I am
[14:53:29] <BigJohnT> for a Mesa THC card
[14:54:08] <mozmck> I see. will it be generic enough to work with others?
[14:54:53] <CIA-1> EMC: 03micges 07master * r1230f5972873 10/src/emc/rs274ngc/interp_convert.cc: Add check for correct digital P index with M62-M65
[14:55:20] <BigJohnT> if they are sending a freq based on voltage
[14:55:35] <mozmck> I'm going to try as I get some time to get the latest candcnc thc working in emc...
[14:56:10] <BigJohnT> does it take over the Z axis like most others?
[14:56:50] <mozmck> it sends up and down signals via two parport pins
[14:57:16] <mozmck> the voltage is read in the thc card.
[14:57:38] <BigJohnT> so it just has two bit pins that say go up or go down?
[14:58:19] <mozmck> yes. it functions basically the same as the MP1000 that Dallur wrote his config for (same company made his)
[14:59:06] <BigJohnT> so your comp needs to know when to apply the correction and how fast to move...
[15:00:21] <mozmck> hmmm, yes I think. it would read the pins, and move Z up or down as fast as it can based on the inputs.
[15:00:40] <mozmck> the speed would be limited by the settings in emc I guess
[15:00:51] <mozmck> or maybe another setting
[15:02:17] <mozmck> there is another pin to indicate a good arc, and there should be no movement without that.
[15:02:34] <BigJohnT> in a nutshell I'm adding an offset to the commanded position if the torch is on and the X+Y velocity is above a threshold
[15:03:18] <BigJohnT> once the torch goes off and the Z is moving up I remove the offset at a rate no faster than the Z is moving
[15:03:23] <mozmck> anyhow, I thought I might could help on your component instead of duplicating efforts if it would work
[15:04:17] <mozmck> so the Z only moves if X and Y are moving?
[15:05:07] <BigJohnT> yes, you set the desired velocity and if it is within the velocity tolerance the offset is applied
[15:05:26] <BigJohnT> kinda like a automagical corner height lock
[15:06:34] <mozmck> oh I see. but otherwise you move the Z up and down based on the voltage reading.
[15:07:08] <mozmck> so the Z slows down or stops moving as the x+y slows or stops for corners etc.
[15:07:53] <mozmck> I guess the mesa card has a way to indicate if there is a good arc?
[15:08:09] <BigJohnT> the plan at the moment is for no offset to be added if the X+Y velocity is below the min
[15:08:18] <BigJohnT> no, that comes from the plasma cutter
[15:08:57] <mozmck> how does it get to emc?
[15:09:08] <mozmck> is it just a switch contact?
[15:09:32] <BigJohnT> yes it is a dry contact inside of the plasma torch connected to a parallel port pin
[15:10:14] <BigJohnT> I have a floating head with a micro switch.
[15:10:23] <mozmck> ok.
[15:10:54] <BigJohnT> so I Z down until the switch closes then move up a known distance then set Z to 0
[15:10:58] <mozmck> that's what our setup uses as well, for touch off
[15:11:27] <BigJohnT> then I move up to peirce height start the torch and wait for the arc ok from the plasma torch
[15:11:51] <BigJohnT> after the peirce delay I move to cut height and take off
[15:12:13] <BigJohnT> as soon as the velocity is up I'll make corrections as needed
[15:12:20] <mozmck> sounds the same as our system.
[15:13:14] <mozmck> how far along is your component?
[15:13:30] <BigJohnT> about 3/4 I guess
[15:13:49] <BigJohnT> I've chopped it up into bits to focus on each part of the process
[15:14:17] <mozmck> yeah. best way I know. let me know if I can help on it.
[15:16:23] <BigJohnT> I have not checked it in since I chopped it up so what is in dev is not working yet
[15:16:27] <mozmck> I'm thinking the main part will be about the same as our thc. if the freq voltage reading were separated out to a different component, the thc component could have two input pins for up and down.
[15:17:19] <mozmck> then those pins could be attached either to parport pins, or two the output pins from your component which reads the freq voltage from the mesa card
[15:17:31] <BigJohnT> that would make it more compatable with the expensive THC systems
[15:18:03] <BigJohnT> and that would make each comp simpler
[15:19:05] <mozmck> I work for Tom at candcnc btw in case you didn't know...
[15:19:32] <BigJohnT> I remember :)
[15:19:46] <mozmck> I'm doing the emc stuff on my own time right now, but he wants me to get all our stuff working with emc at some point.
[15:20:57] <CIA-1> EMC: 03micges 07master * r0f15040e4f86 10/src/emc/ (6 files in 4 dirs): Allow M66 timeout to be fractional number
[15:21:59] <BigJohnT> the only thing I can think of that you loose with a digital up/down is how much up and down is needed....
[15:22:48] <BigJohnT> if it is a lot move faster if it is less than some distance don't bother moving...
[15:22:59] <BigJohnT> a lot of move needed
[15:23:08] <mozmck> hmm, the way ours works is it keeps the up/down on until the voltage is correct. the z should move until the signal turns off.
[15:23:44] <mozmck> the z has to move fairly fast anyhow because the x+y on plasma move pretty fast.
[15:24:20] <mozmck> we do some filtering and averaging in our thc processor, and don't move if the voltage is not far from the set point.
[15:25:05] <mozmck> on our new thc most of those settings are adjustable (dead band, averaging)
[15:27:27] <mozmck> so in your case if your split out the voltage reading part you could do some averaging in that comp.
[15:27:52] <BigJohnT> I guess how fast the Z needs to move depends on the X+Y velocity and the lumpyness of the material
[15:28:20] <mozmck> perhaps also have a z feedrate setting in the thc comp that could be set through a pin or something?
[15:29:01] <BigJohnT> I'm thinking at the moment of using the set velocity to determine how fast the Z moves times some kind of parameter
[15:29:52] <BigJohnT> if I set the velocity target to 100 move the Z at n speed and if it is 400 it would be n*4 or somthing like that
[15:30:28] <mozmck> as far as I've seen it doesn't hurt anything for the Z to move faster even when the machine is not, or the material is flat.
[15:30:54] <mozmck> but if it's too slow if definitely causes problems
[15:31:05] <BigJohnT> :)
[15:32:04] <mozmck> it's basically a like a servo loop. just slower than an actual servo motor.
[15:32:18] <BigJohnT> I'm just thinking of if it moves real fast when going slow there might be some over shoot
[15:32:33] <BigJohnT> yea, I have a pid loop in there :)
[15:32:52] <mozmck> why would the x+y velocity affect the over shoot of the z?
[15:33:15] <mozmck> if there is overshoot there would be all the time wouldn't there?
[15:33:30] <mozmck> at a given z speed that is...
[15:34:06] <BigJohnT> I'm not sure, but my thought process is the slower your cutting the slower your correction needs to be...
[15:34:17] <BigJohnT> and maybe I'm over complicating it
[15:36:23] <mozmck> I think maybe so. you want the z to maintain the correct height as much as possible in spite of the cut speed - I think...
[15:36:58] <mozmck> as long as it's not too fast that it overshoots and goes into oscillations...
[15:37:55] <mozmck> bbl
[15:38:00] <BigJohnT> it would be fairly easy to calc a correction speed based on a correction rate setting and set velocity
[15:38:02] <BigJohnT> ok
[15:49:46] <mozmck> I don't guess I follow you there.
[16:22:29] <CIA-1> EMC: 03cradek 07master * r2947e10bd049 10/src/.gitignore: ignore tags files
[16:41:06] <CIA-1> EMC: 03cradek 07joints_axes3 * r730ea6ebfa33 10/src/emc/ (6 files in 5 dirs): Add analog_input and digital i/o to emctop
[16:41:10] <CIA-1> EMC: 03cradek 07joints_axes3 * ref2d09cca6b9 10/src/emc/usr_intf/axis/scripts/axis-remote.py: add axis-remote --mdi
[16:41:11] <CIA-1> EMC: 03cradek 07joints_axes3 * r8ef53f36ce7d 10/src/emc/usr_intf/axis/scripts/axis.py: Fix the previous commit.
[16:41:14] <CIA-1> EMC: 03cradek 07joints_axes3 * r4b145e62eed3 10/src/emc/rs274ngc/interp_read.cc: Allow N words before O words
[16:41:14] <CIA-1> EMC: 03cradek 07joints_axes3 * rf1bd83105044 10/src/emc/task/emctaskmain.cc: Reenable code to check time spent in main task loop
[16:41:16] <CIA-1> EMC: 03cradek 07joints_axes3 * ra5c7ab2f5ffa 10/src/emc/usr_intf/axis/scripts/axis.py: Added send_mdi_command to provide ability to send mdi commands remotely.
[16:41:19] <CIA-1> EMC: 03cradek 07joints_axes3 * rc296015c0a59 10/src/emc/usr_intf/stepconf/stepconf.py: . is dash-compatible, source is not
[16:41:22] <CIA-1> EMC: 03cradek 07joints_axes3 * r8890a5695ab0 10/debian/.gitignore: a new generated directory
[16:41:24] <CIA-1> EMC: 03cradek 07joints_axes3 * r86253a297b84 10/src/emc/rs274ngc/ (interp_array.cc interp_check.cc interp_convert.cc): Add M67/M68 Enn Qnn - set analog output
[16:41:27] <CIA-1> EMC: 03cradek 07joints_axes3 * r480301507e4b 10/tcl/bin/pickconfig.tcl: fix systems where the directory name "Desktop" is localized
[16:41:34] <CIA-1> EMC: 03cradek 07joints_axes3 * r9c0e8f4c1a6f 10/src/emc/rs274ngc/ (interp_check.cc rs274ngc_return.hh): Improve P-word error detection and message
[16:41:37] <CIA-1> EMC: 03cradek 07joints_axes3 * ra154c59995e9 10/src/emc/usr_intf/axis/extensions/emcmodule.cc: Fix incorrect backplot when motion is very slow
[16:41:40] <CIA-1> EMC: 03cradek 07joints_axes3 * r2a8a98616eec 10/src/emc/rs274ngc/ (interp_check.cc rs274ngc_return.hh): Cleanup and update interp_check error messages
[16:41:43] <CIA-1> EMC: 03cradek 07joints_axes3 * r0737558561d8 10/src/hal/user_comps/pyvcp.py: Add usage info to / cleanup of changes to pyvcp
[16:41:46] <CIA-1> EMC: 03cradek 07joints_axes3 * r7058bc071cbd 10/ (4 files in 2 dirs): add a spindle speed output which is in revolutions per second
[16:41:49] <CIA-1> EMC: 03cradek 07joints_axes3 * r1230f5972873 10/src/emc/rs274ngc/interp_convert.cc: Add check for correct digital P index with M62-M65
[16:42:00] <CIA-1> EMC: 03cradek 07joints_axes3 * r0f15040e4f86 10/src/emc/ (6 files in 4 dirs): Allow M66 timeout to be fractional number
[16:42:03] <CIA-1> EMC: 03cradek 07joints_axes3 * r74d5e3f2bdba 10/src/emc/usr_intf/axis/extensions/emcmodule.cc: Remove more unused fields from emc.stat
[16:42:06] <CIA-1> EMC: 03cradek 07joints_axes3 * rd6266fd4b92f 10/src/emc/ (5 files in 4 dirs): Add analog_input to EMC_MOTION_STAT and emctop
[16:42:09] <CIA-1> EMC: 03cradek 07joints_axes3 * r2947e10bd049 10/src/.gitignore: ignore tags files
[16:42:11] <CIA-1> EMC: 03cradek 07joints_axes3 * r5cfc9cc48a95 10/src/emc/ (4 files in 2 dirs): Remove old AUX io code
[16:42:14] <CIA-1> EMC: 03cradek 07joints_axes3 * rdf5c85a65c92 10/src/emc/motion/ (command.c control.c mot_priv.h motion.c motion.h): Enable analog_input code in motion
[16:42:17] <CIA-1> EMC: 03cradek 07joints_axes3 * r8665663b5a8d 10/src/emc/ (4 files in 2 dirs): Remove unused EMC_AUX_AIO_WRITE
[16:42:24] <CIA-1> EMC: 03cradek 07joints_axes3 * r3b99b93a100a 10/src/emc/usr_intf/stepconf/stepconf.py: stepconf fixes for non-standard directory installs
[16:42:27] <CIA-1> EMC: 03cradek 07joints_axes3 * r99db5d2e7d40 10/src/emc/ (task/emctaskmain.cc usr_intf/axis/extensions/emcmodule.cc): Add ability to change digital/analog output from python code
[16:43:55] <micges> cradek: wow
[16:44:09] <jmkasunich> was that a "keep the branch current" push?
[16:44:52] <jmkasunich> on the commit list, each commit is tagged with the original author's name, but in here they are all cradek
[16:55:32] <cradek> yes that's all it was
[16:55:45] <cradek> here the name is the 'pusher', in the email it's the author
[16:57:06] <micges> cradek: will be ok that I will work little on joint_axes3, or you have some bigger stuff to work at it?
[16:57:19] <cradek> please do
[16:57:34] <cradek> I'm not working on it, I'm only keeping it up to date so interested persons can work on it easily
[16:57:56] <cradek> it runs but I have not even tested it much.
[16:59:23] <micges> ok
[17:21:46] <BJT-Hardy> I just did a small edit on main.lyx and now I get some errors when I run make
http://pastebin.ca/1483975
[17:22:35] <cradek> is your disk full?
[17:23:24] <BJT-Hardy> I don't know... let me check
[17:24:08] <cradek> I don't really a meaningful error except broken pipe on write - maybe I'm just not spotting it
[17:24:15] <cradek> s/really/see/
[17:24:47] <BJT-Hardy> the docs/src/lyxtree.py stuff
[17:25:02] <BJT-Hardy> and the lyx2lyx
[17:25:09] <BJT-Hardy> I've never seen that before
[17:25:15] <cradek> yeah I see that, but it doesn't mean anything to me :-)
[17:25:23] <BJT-Hardy> LOL
[17:25:25] <cradek> sorry for being obscure
[17:26:14] <cradek> still guessing full disk or something else goofy like that
[17:26:35] <BJT-Hardy> it says I have 164 Gb free space
[17:27:12] <cradek> hmm
[17:27:32] <cradek> might have to wait for jepler - I don't know what it means
[17:27:51] <BJT-Hardy> ok, thanks for looking
[17:28:48] <cradek> meanwhile, I'm procrastinating cutting a single point thread on a $45 part that has to be perfect - and I only have one
[17:29:23] <BJT-Hardy> don't have any test material laying about?
[17:29:50] <cradek> it's steel and I don't have any other steel that big
[17:30:18] <cradek> I guess I really should cut it in Al first though.
[17:30:38] <cradek> it won't act too differently I suppose
[17:30:39] <jtr> logger_dev: bookmark
[17:30:39] <jtr> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-07-04.txt
[17:31:27] <cradek> bbl
[19:17:36] <alex_mobile> * alex_mobile is a daddy
[19:21:18] <skunkworks> alex_joni: congradulations!!!!
[19:21:34] <skunkworks> Long labor?
[19:35:56] <cradek> alex_mobile: everyone doing well??
[20:47:53] <jepler> alex_mobile: congrats
[20:49:33] <jepler> bjt: that error doesn't mean anything to me. if you can send me the file you were editing (gcode_main.lyx?) can see if it happens here.
[20:51:24] <jepler> there are two python tracebacks there. the top one seems incomplete. the bottom is after the error occurred, whatever it was, and is only a symptom, not a cause
[20:58:06] <alex_joni> cradek: yeah, everyone doing well
[20:59:09] <jepler> it looks like it's probably my own fault that the top one is incomplete. but I still will need the lyx file to diagnose / fix the problem.
[21:05:06] <micges> alex_joni: congratulations
[21:06:57] <alex_joni> thanks all
[21:41:48] <micges> good night all
[21:44:49] <cradek> yay, my tricky thread came out right
[21:46:20] <jepler> yay!
[21:47:47] <CIA-1> EMC: 03jepler 07master * r373fc0df17ee 10/docs/src/gcode/main.lyx: fix typo
[21:48:18] <jepler> g-G95 is Units per Reveloution Mode.
[21:48:18] <jepler> +G95 is Units per Revoloution Mode.
[21:48:22] <jepler> well I *tried* to fix the typo
[21:49:28] <CIA-1> EMC: 03jepler 07master * ra94d9a9ddc63 10/docs/src/gcode/main.lyx: fix typo harder
[21:49:29] <cradek> well "reveloution" is pretty amazing
[21:49:29] <CIA-1> EMC: 03jepler 07v2_3_branch * r2462dbce0902 10/docs/src/gcode/main.lyx: fix typo
[21:50:25] <alex_joni> heh
[21:50:33] <jepler> how'd I do this time?
[21:50:44] <cradek> I'm scared to look
[21:51:48] <jepler> I don't blame you
[21:53:12] <jepler> I am tempted to do this and push the result: $git merge --strategy=ours origin/joints_axes origin/joints_axes2
[21:53:20] <jepler> (while on joints_axes3)
[21:53:54] <alex_joni> what does ours do?
[21:54:15] <jepler> it means "make the result of the merge exactly what's in this tree" (it ignores the actual contents of the other two trees)
[21:55:37] <cradek> why?
[21:56:17] <cradek> you could rename them (all three) so it's obvious which are the old ones
[22:00:28] <jepler> this makes them all lead into the current branch. then, in git rules, you can delete the other branches
[22:00:37] <jepler> it's probably not really a sensible thing to do
[22:23:45] <CIA-1> EMC: 03jepler 07master * r5b74f31c07be 10/src/emc/sai/saicanon.cc: print out this canon message