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