Back
[18:04:23] <alex_joni> SWPadnos: ?
[18:04:37] <SWPadnos> not /kick, kick in the backside :)
[18:04:57] <alex_joni> yeah.. figured that.. but why?
[18:05:04] <SWPadnos> because they weren't here ...
[18:05:15] <alex_joni> oh
[18:05:18] <SWPadnos> I wonder if it would be better to run them as emcboard though
[18:05:25] <alex_joni> the -emc was here
[18:05:39] <SWPadnos> so it was. odd
[18:06:17] <SWPadnos> cradek suggested setting up a cron job for it - can you do that?
[18:06:58] <alex_joni> not quite.. I never figured a way to detect if they are in the channel or not
[18:07:11] <alex_joni> the process might still be active, but detached from the irc server
[18:07:25] <SWPadnos> mmm
[18:07:32] <alex_joni> so at best we can set it up once every 24h to log out and back in
[18:07:40] <alex_joni> bbl
[18:07:43] <SWPadnos> ok
[18:27:44] <rayh> question about motion.spindle-speed-out
[18:27:52] <rayh> It lists rpm.
[18:28:11] <rayh> How would you convert that to work an m5i20 dac.
[18:28:53] <rayh> You'd have to know spindle max
[18:37:01] <SWPadnos> do you have anything attached to the PWM output (like the 7i33)?
[18:37:30] <rayh> I'd not thought that far ahead.
[18:37:30] <SWPadnos> or does the spindle driver have a PWM input?
[18:37:33] <SWPadnos> heh
[18:38:20] <rayh> If I did use the 7i33 the pwm would become +-10 volt
[18:38:22] <SWPadnos> it's just an analog output, so you can set the max, min, and scaling parameters such that an input of 1 (RPS from motion, I think) gives you whatever output you need for 60 RPM
[18:38:23] <SWPadnos> correct
[18:39:05] <rayh> so how would I tell the pwm on the 5i that 3000 rpm was half speed? Assuming a 6000 rpm spindle.
[18:39:35] <SWPadnos> one sec. let me check a couple of things in the source
[18:39:38] <rayh> okay, there are scaling parameters in the m5 module.
[18:40:58] <SWPadnos> heh:
http://www.geocities.com/tokyo/towers/2060/catfood.jpg
[18:41:52] <SWPadnos> actually, the list of pins/params for a 5i20 DAC would be good
[18:42:45] <rayh> I see 'em using halshow
[18:44:23] <SWPadnos> stupid connection
[18:45:36] <SWPadnos> ok. regardless of the actual output, the driver thinks the range is +/- 10V
[18:46:00] <SWPadnos> so 50% (3000 / 6000) is 5V
[18:46:23] <SWPadnos> 3000 RPM is 50 RPS, so you want an input of 50 to yield 5V output
[18:46:37] <SWPadnos> you need to set dac.whichever.gain to 5/50 or 0.1
[18:46:46] <SWPadnos> (I think :) )
[18:47:33] <SWPadnos> of course, if your VFD has a 12V input range, you'd need to change the gain ...
[18:47:44] <SWPadnos> if you don't have a 7i33, you need to change the gain ...
[18:50:22] <rayh> How is this percent of max handled with an axis.
[18:50:44] <SWPadnos> I'm not sure it is (or possibly I'm not sure what you mean)
[18:50:55] <maddash> is there any way to speed up the execution of a gcode program?
[18:50:59] <rayh> If you specify 50 IPM
[18:51:01] <SWPadnos> get a faster computer
[18:51:17] <rayh> on a machine that will go 150 ipm
[18:51:34] <rayh> then the signal to the dac ought to be 3.3333
[18:51:34] <SWPadnos> if you ask for 50 IPM, then all axis does is tell the motion controller to go to 50 RPM (or 0.86666 IPS)
[18:52:04] <SWPadnos> I don't think any of the GUIs have a way of knowing the max spindle speed (??)
[18:52:06] <maddash> SWPadnos, that's not funny...I'm using a 3ghz Pentium D, so slowness of emc itself is not an issue...
[18:52:10] <SWPadnos> heh
[18:52:38] <SWPadnos> maddash, what's slow though? is it the speed at which the part is milled? the speed at which the file is loaded? ...
[18:52:47] <rayh> 3gh is a maddash:)
[18:53:06] <maddash> SWPadnos, the milling part
[18:53:19] <SWPadnos> ok, then you needa faster milling machine ;)
[18:53:24] <maddash> SWPadnos, kind of like the feed rate...
[18:53:42] <maddash> SWPadnos, I''m not attached to any machine, just reading from mini's backplot
[18:54:18] <maddash> SWPadnos, chging f100 to f500 didn't do much...
[18:54:18] <rayh> ah. you can set feedrate override in the ini to 500% and speed it up that way.
[18:54:22] <SWPadnos> ah. and are you using one of the sim configs, or a stepper_<something> config?
[18:54:30] <maddash> SWPadnos, correct.
[18:54:36] <SWPadnos> which one - that was multiple choice
[18:54:39] <maddash> rayh, what's the ini parameter?
[18:54:46] <rayh> Only you will not be able to go faster than max_vel
[18:54:47] <SWPadnos> MAX_OVERRIDE or similar
[18:55:04] <maddash> SWPadnos, sorry, I skimmed your msg to the last bit...I'm using stepper_inch, with DISPLAY=mini
[18:55:26] <rayh> MAX_FEED_OVERRIDE = 5
[18:56:02] <rayh> What feedrate are you using for cutting?
[18:56:22] <SWPadnos> ok. change to sim_soemthing, and increase the MAX_VELOCITY and MAX_ACCELERATION parameters everywhere you find them in the ini
[18:56:30] <rayh> And what is MAX_VELOCITY
[18:56:45] <SWPadnos> and increase the fedrate override to some insanely high number, like 20
[18:57:13] <SWPadnos> that will let you run programs at 20x the programmed speed, subject to the VELOCITY settings you chose
[18:57:33] <maddash> rayh, f500
[18:57:44] <rayh> mm?
[18:57:55] <SWPadnos> (the speed of G-code execution is limited by: the programmed feed rate, the trajectory limits, the axis limits, and the speed at which steps can be generated)
[18:57:58] <maddash> <rayh> What feedrate are you using for cutting?
[18:58:16] <SWPadnos> inches - it's the stepper_inch config
[19:00:53] <rayh> maddash: Are you trying to preview the path to be milled, if so, probably axis would be the better display to use.
[19:01:36] <maddash> rayh, why's that?
[19:01:49] <maddash> SWPadnos, I changed MAX_ACCELERATION and MAX_VELOCITY to ten times their original settings...nothing changed much, at least not in DISPLAY=mini
[19:02:24] <SWPadnos> and you restarted emc?
[19:02:48] <SWPadnos> axis provides a preview when you load the file
[19:03:02] <SWPadnos> you can rotate, translate and zoom the image
[19:03:11] <SWPadnos> it shows the extents of motion on each axis
[19:03:35] <SWPadnos> you can click on a segment in the preview and see what line of G-code produced it and vice versa
[19:04:50] <maddash> SWPadnos, but what does that have to do with the feed rate?
[19:05:13] <SWPadnos> if you're previewing G-code, then you don't have to run the program with AXIS - that's why Ray asked what you were doing :)
[19:05:23] <maddash> SWPadnos, axis isn't running - "ImportError: no module named minigl"
[19:05:40] <SWPadnos> this is your stripped-down install, right?
[19:06:03] <rayh> ah sorry about that advice.
[19:06:15] <maddash> ah. no, I'm not previewing gcode, i have autocad for that. I'm try to simulate the motions of the stepper controller in realtime b/c I don't have the controller board yet.
[19:06:46] <maddash> SWPadnos, hah, you still remember? no, I recompiled v2.1a with --enable-run-in-place
[19:06:47] <SWPadnos> then you should leave it at "real time", not "compressed time" ...
[19:06:50] <SWPadnos> ok
[19:07:19] <rayh> Okay. a feedrate of 500 IPM ought to be pretty fast.
[19:07:27] <SWPadnos> regarding the MAX_* parameters: you have to change them in the [TRAJ] section and in each [AXIS_n] section
[19:07:29] <maddash> SWPadnos, even in "real time," mini isn't giving out the cmds fast enough...unless the backplot and the actual output pulses are not in sync...
[19:07:37] <SWPadnos> they aren't
[19:07:54] <SWPadnos> backplot samples the position every so often, and updates the plot
[19:08:13] <maddash> SWPadnos, ok, what about the gcode cmd list below the backplot?
[19:08:13] <SWPadnos> it doesn't get a full buffer of every point between two sucecssive samples
[19:08:50] <SWPadnos> mini (and all the UIs) are userspace components, and as such they (a) don't run too often and (b) don't necessarily have accurate delays between samples
[19:09:08] <jepler> and (c) may be looking at an outdated copy of the information about the state of the machine
[19:09:11] <SWPadnos> if you speed it up so the entire program "runs" in <100 ms, then mini will show you one line - from start to end
[19:09:13] <SWPadnos> right
[19:09:47] <SWPadnos> you can increase the frequency at which the UI runs by changing a parameter in the [DISPLAY] section of the ini, I think
[19:10:03] <SWPadnos> or possibly somewhere else - I don't remember the parameter name
[19:10:24] <jepler> I don't know whether the UIs obey that or not -- I know axis does not
[19:10:28] <maddash> the polling freq isn't the problem - I don't mind a jumpy display, as long as the display jumps from one cmd to another quickly...
[19:10:49] <SWPadnos> it doesn't jump from command to command. it jumps from position sample to position sample
[19:11:20] <SWPadnos> if you command a full circle, and it takes less time than the sampling period, there will be no apparent motion, and the backplot will show nothing
[19:11:44] <maddash> SWPadnos, by "cmd," I meant the sampled cmd in the list displayed below the backplot
[19:12:22] <SWPadnos> I think I don't understand what you're trying to see with this setup
[19:12:52] <SWPadnos> if you run the G-code really fast and don't care about the backplot, what information does that give you?
[19:13:41] <cradek> I think this conversation belongs on #emc because it's not about development
[19:13:55] <SWPadnos> ok by me
[19:14:09] <maddash> oh, there's an #emc, too?
[19:14:11] <jepler> yes
[19:14:18] <maddash> thanks
[19:14:18] <cradek> yes that's the primary channel
[19:14:45] <cradek> I didn't mean he had to leave
[19:15:13] <cradek> it just squashes any other converation about development if basic user questions are going on here
[19:15:19] <SWPadnos> whichever :)
[19:15:35] <skunkworks> how about those packers?
[19:15:58] <cradek> * cradek rains on the parade
[19:16:03] <SWPadnos> doesn't that belong in #stupid-sports-talk
[19:42:31] <SWPadnos> you said it
[20:04:08] <cradek> rayh: I wonder if we should tell eric that step generation in the mesa is probably coming up relatively soon
[20:04:54] <jepler> if we obey our "no new features" rule it won't be in a released version until 2.2 in 2008
[20:04:58] <jepler> that's not soon
[20:05:07] <rayh> cradek: Sure. Will that be configurable so that we can run step from some and pwm from others?
[20:05:25] <cradek> jepler: very true
[20:05:36] <cradek> rayh: you'd have to ask jmk and swp :-)
[20:05:49] <rayh> Ah okay.
[20:05:52] <cradek> rayh: (I doubt I'll be much help writing it)
[20:06:13] <rayh> me either.
[20:08:20] <cradek> I know I would sure like it that way too... for example the nist lathe currently uses both (software) pwm and step generation
[20:08:23] <jepler> if I can channel them for a moment, they've talked about having a "mix and match" at compile time of the fpga firmware, with the single driver able to use any combination. we'd include a handful of firmwares which we hope will be satisfactory for all but a few users.
[20:08:40] <cradek> that sounds great
[20:10:25] <rayh> good.
[20:10:39] <rayh> I see that Pluto's pin and such files are copyright Altera.
[20:11:14] <jepler> yeah I'm not entirely pleased with that
[20:12:10] <jepler> s/entirely//
[20:12:36] <jepler> but it's a bit late to decide to file off that copyright notice without checking in the file
[20:13:02] <cradek> cvs admin -o
[20:13:22] <rayh> I just wondered if we'd get a complaint from someone.
[20:13:55] <cradek> those are the generated output files right?
[20:14:29] <jepler> cradek: no, the qsf file in particular is a set of assignments I created in the GUI, and which are used during the process of creating the .rbf firmware file
[20:14:53] <jepler> rayh: we will now
[20:16:31] <cradek> so you could replace it all with your vhdl files and a long complicated list of what to click in their gui to generate the firmware image
[20:16:54] <jepler> yes, in principle
[20:17:10] <jepler> I'd hate to prepare such a list
[20:17:12] <cradek> seems like that's the alternative
[20:17:14] <rayh> IMO we got a GPL from mesa for similar stuff, didn't we?
[20:17:18] <cradek> yeah of course it would be terrible
[20:17:45] <cradek> I don't know how the mesa stuff worked exactly
[20:18:07] <rayh> Is the .rbf file the actual firmware?
[20:18:19] <jepler> altera is the manufacturer of the fpga chip itself, not the board. their IDE puts copyright notices on some of the files you create while using the IDE
[20:18:28] <jepler> yes, the .rbf is the actual firmware
[20:18:47] <rayh> Do you know if there is a copyright embedded in that?
[20:19:10] <jepler> there's not a string "Copyright", no
[20:19:57] <rayh> What's the ascii for the copyright notice?
[20:20:30] <jepler> 0xa9 ?
[20:20:49] <jepler> I'm not sure what you're getting at
[20:21:10] <rayh> I wonder if the use that to assign a copyright to the file.
[20:21:58] <cradek> I don't think that file has anything other than the fpga program in it
[20:22:24] <cradek> (it's loaded very directly into the device)
[20:22:58] <rayh> But any file can be copyright. It matters not what it contains.
[20:23:51] <jepler> yes, obviously that .rbf file is Copyright Me
[20:23:52] <cradek> yes they might have evil bits in the "agreement" those other comments mention
[20:30:04] <rayh> gotta run to town. See you guys.
[20:30:08] <jepler> see you ray
[20:34:20] <jepler> cradek: does "touch off" work for you in HEAD?
[20:34:36] <cradek> yes I just used it
[20:34:39] <jepler> huh
[20:34:43] <jepler> Exception in Tkinter callback
[20:34:48] <jepler> AttributeError: comment
[20:34:53] <jepler> I get this ^^^
[20:35:00] <jepler> and any number I enter is not accepted
[21:41:24] <alex_joni> * alex_joni wonders if we want to keep both VCP and pyVCP
[21:41:45] <alex_joni> it might be easily confusing for users, at least the docs need to get a lot clearer
[21:42:36] <cradek> jmkasunich said he prefers to ditch the old vcp
[21:43:01] <alex_joni> I kinda feel the same way
[21:46:38] <lerneaen_hydra> lerneaen_hydra is now known as lerneaen_hydra_p
[21:46:48] <lerneaen_hydra_p> lerneaen_hydra_p is now known as hydra_posthumous
[21:51:03] <alex_joni> alex_joni is now known as robin_sz
[21:51:22] <hydra_posthumous> hydra_posthumous is now known as alex_joni
[21:51:45] <robin_sz> robin_sz is now known as alex_joni
[21:53:30] <lerneaen_hydra__> lerneaen_hydra__ is now known as lerneaen_hydra
[21:58:21] <lerneaen_hydra> lerneaen_hydra is now known as hydra_posthumous
[21:59:32] <skunkworks> skunkworks is now known as credak
[22:00:28] <hydra_posthumous> hydra_posthumous is now known as jeplar
[22:01:44] <jeplar> jeplar is now known as lerneaen_hydra
[22:01:45] <credak> credak is now known as skunkworks
[22:03:09] <sudo_maddash> why is it the rtai kernel cannot have acpi/smp compiled in?
[22:03:16] <sudo_maddash> sudo_maddash is now known as maddash
[22:03:37] <alex_joni> acpi can cause rt latencies
[22:03:53] <awallin> I didn't want to step on jmk's toes, so I didn't remove the vcp documentation from vcp.lyx
[22:03:55] <alex_joni> for example power saving or cpu frequency scaling
[22:04:22] <maddash> but that shouldn't happen, esp. when you have a 3ghz pentium d, rah?
[22:04:25] <alex_joni> awallin: I didn't remember that he said he wants vcp to go, now that pyvcp can replace it.. but I think I remember it now
[22:04:34] <alex_joni> maddash: especially on a 3ghz pentium
[22:04:37] <maddash> and what's wrong with smp?
[22:04:43] <maddash> alex_joni, how so?
[22:04:57] <alex_joni> maddash: the newer the processor the crappier the realtime performance (not quite always true, but in most cases)
[22:05:12] <maddash> alex_joni, my colleague tells me that latency isn't an issue given the insanely high clockspeed
[22:05:26] <alex_joni> maddash: lets move to #emc please
[22:07:37] <awallin> alex_joni: yep, I think he mentioned it on the mailing list, but I'll leave deleting stuff from cvs to someone else. I can take care of the documentation over the next few days.
[22:07:56] <alex_joni> ok, great
[22:18:17] <awallin> should I just go ahead and delete the old VCP documentation right now? It's going to be in cvs for a while still even if I delete it now I guess?
[22:18:25] <alex_joni> please do
[22:18:35] <alex_joni> "It's going to be in cvs forever.."
[22:19:22] <awallin> jepler: are you there?
[22:21:26] <awallin> it seems the .lyx to html conversion does not like my XML markup very much...
[22:21:48] <alex_joni> awallin: try formatting the lines as lyx-code
[22:22:38] <awallin> they are all lyx-code, but still the end tag </something> is usually, but not always, missing from the html output
[22:23:20] <alex_joni> oh darn
[22:23:31] <alex_joni> wonder if there's a <pre> equivalent in lyx
[22:23:54] <alex_joni> you might want to try escaping \< or something like that
[22:24:40] <awallin> in the pdf on the other hand, everything looks fine.
[22:24:54] <awallin> but the screencaps look worse in the pdf and better in the html
[22:25:14] <alex_joni> right.. did you change the output % on the screencaps?
[22:25:50] <awallin> for the big image I did, it's reduced to 50% and it looks better in the pdf
[22:26:00] <awallin> the small ones are 100% and look blocky in the pdf
[22:26:18] <alex_joni> right
[22:28:28] <awallin> I might send an email to the devel list about the tag formatting in the html output
[22:28:44] <alex_joni> let me google for a while
[22:28:44] <jepler> awallin: hmph -- latex2html should do "the right thing" to make < and > appear in the output
[22:29:11] <jepler> lots of things about the html are less than satisfactory :(
[22:29:18] <awallin> jepler: hi, ok, no email needed I guess. the strange thing is that sometimes it works, and sometimes the end tag is missing
[22:30:00] <jepler> some of the images are scrambled or just plain missing...
[22:31:34] <alex_joni> jepler: the images missing are the ones linked from different dirs
[22:36:24] <alex_joni> awallin: sorry.. no idea :(
[22:36:30] <alex_joni> jepler: at least some of them..
[23:26:59] <jepler> it tempts me to back-port some stuff from 2.2
[23:27:02] <jepler> in HEAD you get messages like this:
[23:27:03] <jepler> STEPGEN: Channel 0: The requested maximum velocity of 55999 steps per second is not attainable.
[23:27:06] <jepler> STEPGEN: The maximum number of steps possible is 10000 per second
[23:27:10] <jepler> and the first is even shown to the operator
[23:27:29] <alex_joni> it would be nice in 2.1
