EMC: 03seb 07master * rdff6b257abcc 10/debian/ (control.in emc2.files.in rules.in): switch from dh_python (deprecated) to dh_pysupport
EMC: 03jepler 07master * r140d41cde03c 10/src/po/it.po: i18n: update Italian translation
[13:32:15] <skunkworks> http://www.cnczone.com/forums/cncbrain/72401-cncbrain_users-13.html
The CNC Brain guy first approached the Mach3 guys about using their front end for the CNC Brain product but then backed out of the deal. The CNC Brain founder then went on to roll his own, but it never really got off the ground.
His initial sales pitch was very attractive but there was little substance behind the sales pitch. The economy is still not coming back quickly leaving some broke companies in it's wake. I doubt that Mach3/Artsoft is doing very well either.
I have to say - getting in deep with emc2 really has affirmed emc's awesomeness
but you keep finding stuff that doesn't work...
that is a good thing though
well I suppose they're all fixed now, though
make me feel like I am contributing in an odd way. ;)
I keep forgeting to try the estop/tool prep patch.
(on the actual machine)
that's a way you 'pay' for emc :)
>> has affirmed emc's awesomeness - I agree ... :-)
Skunkworks: I have missed some of your recent vids but it sounds like your machine is doing very well.
getting there. :)
Are there many more of those machines around still?
did you see http://www.youtube.com/watch?v=KplU8hkI0AQ
Dave911: we have 2 (one we are taking apart for spares) I have only seen references to them in sales.
I don't know of any
I was wondering after doing this one .. if you are going to look for more machines to convert. The first one is always the tough one..
I did see that video - very nice ..
Dave911: last one was this http://www.youtube.com/watch?v=9xDPqFXo_5w&feature=mfu_in_order&playnext=1&videos=ul04bA3-tKk
oh sure - we are always on the lookout for a nice vmc cheap and local ;)
cradek: why may axis fail during execution of big ngc file?
i only imagine opengl and out-of-memory
dmesg is clear, only line about segfault in axis process
i've started same ngc file on my testbed machine with only stepper drive to check it against 10.04 release
I haven't seen that failure
btw axis is eating 250M of memory on my testbed :)
i suspect opengl issues since it tries to draw all paths
and there are many of them
240k lines in ngc file
sure, it might be your opengl
psha: can you paste it at filebin.ca ? I would like to test Axis with it
[15:27:25] <psha> http://psha.org.ru/p/second.ngc.gz
if it's really opengl issue then it may be good stress test :)
but my D510M performing fine with it...
micges: is it loading fine?
so it will work fine
its eats 250mb of ram
i've asked for details and it's reported to sometimes crush axis on load
you have glx disabled or enabled?
you mean graphic driver?
I have software rendering only
i've reported back that it's opengl issue :)
loads fine for me too (using sim, nonrt kernel, nvidia binary driver)
thanks a lot
you could put (AXIS,stop) magic comment to make AXIS stop generating preview
i'll try to switch to software rendering on that machine
but it'll be on thursday...
when i'll bring new D510M replacement there
yuck, terrible gcode
circles are made of little lines
fine here. 240MB RES according to top.
also nvidia, sim..
20442 cradek 20 0 271m 232m 17m S 15 23.2 1:59.56 axis
(and the preview isn't all that *useful* either... way too many lines to actually see anything)
i'll try disabling AXIS preview too
so i'll definitely know what happens
thanks a lot for testing again
psha: no issues with nvidia binary driver
apropos of nothing, the preview plot becomes more useful when drawn like this: http://emergent.unpy.net/files/sandbox/preview-plot-alpha.png
what did you do?
it uses an opengl blend mode
1 traverse through pixel = 1/3 brightness. 2 ~= .55 brightness, 3 ~= .7 brightness, tending towards 1.0 brightness when many lines are crossing at the same spot
before the shape was more or less a white blob, as I assume you saw
and how blend mode may be enabled?
lib/python/rs274/glcanon.py | 42 ++++++++++++++++++++-----
src/emc/usr_intf/axis/extensions/emcmodule.cc | 6 ++-
2 files changed, 38 insertions(+), 10 deletions(-)
I'll get the patch up, just a second
[16:08:12] <jepler> http://emergent.unpy.net/files/sandbox/0001-axis-use-a-blend-mode-to-draw-preview-plot.patch
(patch is against master, won't work as-is on 2.4)
how does it look with more normal programs?
you could increase (or make user-adjustable) the line width
could make alpha another view option
it's working nice
[16:12:29] <jepler> http://emergent.unpy.net/files/sandbox/preview-plot-alpha2.png http://emergent.unpy.net/files/sandbox/preview-plot-alpha3.png
that sure helps the torus preview...
wonder how badly it hurts software rendering?
I'm not sure.
now that I am thinking about it more, it might be closer to a wash
old pipeline is approximately: read depth buffer, compare computed branch, conditional branch, write depth buffer, write color buffer
s/compare computed branch/compare computed depth, conditional branch/
new pipeline is approximately: read color buffer, perform blend operation, write color buffer
compared to memory access, I think a little arithmetic like (a*b + c*d) >> 8 may be free
particularly if mesa is able to use mmx and/or sse
logger_dev: hanging in there?
I'm logging. Sorry, searching removed.
indeed part looks much better
I'd expect mesa to use SSE/MMX if available (I can't imagine it being usable without that)
yes, I think so
so actual sw rendering is needed :)
that's what mesa is :)
it also works with hardware rendering
I am pretty sure any current accelerated opengl will accelerate this operation.
it's almost the most basic transparency effect
i mean actual sw rendering tests are needed for this feature :)
i've tried xephyr but it refuses to work with ati fglrx driver
and i have to use that fglrx at least for a month or two
that patch runs nice on my laptop - using whatever the default driver is for my ati card
Do hal pins "know" that they are wired? (or can the driver figure it out?)
you can test for a connection in your module
like if (pin isn't pointing to dummy variable)
but you may have to hold onto some extra data to do that
(not the fglrx closed source driver)
I guess that has to happen in the realtime code?
it would, but it shouldn't be necessary
if it is, you probably have a design error :)
I am considering merging the two bldc drivers.
As the 8i20 sort-of wants a hybrid version.
My idea is that if there are only hall sensors and no encoder it runs trapezoidal commutation. If there is only an encoder it runs sinusoidal with a startup wobble to align, and if it has both it will start up using the Hall sensors, then switch to using the encoder and sinusoidal commutation once it sees a change in hall-sensor state
It is probably better to do it from the config string though.
andypugh: re your recent list post, I asked pcw for a .vhd file that will be appropriate for 5i20+7i39. once I get it, I'll build a bitfile and let you know where I put it
andypugh: if you'd be willing to continue working with the guy on the web bbs
PCW replied on the forum that he will build one today.
But I guess it might as well be in the main firmware set too.
I didn't see that
andypugh, I would do it from the config string, or have a mode pin/parameter
I am not clear how the split between your firmware builds and PCWs builds works.
PCW wants to support his customers in every way - the emc project wants to make sure sources and binaries we distribute match (for GPL reasons) and the best way for us to do that is build the binaries from the sources ourselves
you as a mesa user can use firmwares from either source or even build your own
So the firmwares are logically identical, but philosophically distinct? :-)
(I don't know if that helps)
well I think we even agree on the philosophy
In "Comp" does the "personality" string have to be called "personality"?
andypugh: at the moment, yes.
OK, so if I want a config such that you can say "loadrt bldc config=1,2,3,3,2,1" I would probably need to start in comp then edit the C? (or start in C)
andypugh: does this influence the pins/parameters your instances create, or something else?
It influences the pins, yes.
mode 1 might be encoder-onle, mode 2 hall-only and 3 would be both.
And then you probably wouldn't create the hal pins that weren't used.
Or I could write a bldc_hybrid comp to join the family.
so the only thing lacking is the ability to name the module parameter "config" instead of "personality"?
I would probably be wanting to only have one parameter. (rather than a count and a personality)
you can use option count_function .. get_count() would look at the personality array and figure out how many were specified (e.g., nonzero)
Am I guilty of not reading docs?
oh the docs are crummy
maybe it's not hard to add "personality with a different name", I'll look into it after I'm full of food
I think option count might do.
Let me experiment.
It looks like option userinit is intended to allow userinit(int argc, char ** argv) parse the command line, but nobody has ever used it, so I can't tell how
andypugh: that's for userspace components, which have an argc and argv
I don't think anybody's actually using comp for userspace components, though
either I'm testing software rendering wrong, or the performance is really excellent, or my machine is way overpowered (particularly compared to a system doing software stepgen)
.. but the performance with second.ngc and alpha rendering is still very good
I am serioulsy considering writing a userspace comp for configuring the 8i20 EEPROM
how will that work? A userspace component can't access the hardware directly..
I was hoping to twiddle the raw interface
I see. that makes sense.
If the RT driver (somehow) exports the value of its first register address, then the comp can write to the required registers with raw to send commands and data to the device.
jepler: I didn;t notice any speed decrease.
how can I tell what I am using for video?
acellerated/hardware or not.
skunkworks: $ glxinfo | grep '^OpenGL'
.. if you have the glxinfo program installed
in the alpha rendering mode, it becomes unclear what parts of the preview plot are in front of the backplot
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV730 9488) 20090101 TCL DRI2
OpenGL version string: 1.5 Mesa 7.7.1
runs great :)
I'm not satisfied with how it looks combined with backplot. http://emergent.unpy.net/files/sandbox/unclear.png
the red dome part in the backplot should be 'behind' the backplot, but it doesn't look like it is
that is a bit ugly
can you make the backplot line the same size as the preview - just red?
aaahhhh. so much easier to trust the digital caliper when the numbers aren't flashing and faded :)
1 pixel lines are better but not ideal
btw what is DTG?
distance to go
the remaining distance in the current move
is blending used for backplot?
I'd have to refresh my memory about that
with 1px lines it's only a bit better
[18:50:08] <psha> http://psha.org.ru/p/backplot-1px.png
that does look better though.
psha: do you happen to know what software generated this gcode (second.ngc)?
i may ask
by hand seems to me ;P
micges: 20 enslaved citizens were writing it for a month!
chinese i guess.
tajiks are cheaper here...
here are many workers from asian ax-ussr republics
at least here thay may found job
nearly every family there have one or two members working in large cities here
when my brother was on trip in tajik mountains he talked to lot of people
and most of them have relatives working here
for example several years ago one man leaving near afgan border told my friend that new subway station will open in moscow in a short feature
and indeed it was open when he told
since he was working there
[19:49:35] <PCW> http://filebin.ca/dhushw
is pin file for 72 I/O pin (5I20 etc) card with 3X 7I39s
(I already made .bit and.pin files and posted them in the forum)
thank you PCW
jepler: all those additional bit/pin files for cards supported by emc are stored somewhere?
(index latch stuff and such)
micges: I occasionally make special bitfiles for people, but I don't keep track of them. Unless I forget, I enclose the pin.vhd file which is the only source file that differs from the sources in the hostmot2-firmware source tree
everything I keep track of is in the hostmot2-firmware packages
How long do files stay on Filebin for?
I think you can choose that
I think I selected a month
That should catch him then.
jepler: I see
I think I spotted a problem today:
bldc-sine.N.scale float rw (default: 512)
The number of encoder counts per electrical revolution. eg counts/2 for a 4-pole motor, counts/3 for a 6 pole etc. There is a 50% chance that this parameter will need to be negative for proper function.
I have never seen an encoder with an integer-divisible-by-three number of edges. So I think there is a danger of cumulative error if they don't type enough threes after the decimal point?
Of course, it rather depends on how many complete revolutions the encoder does.
and this would manifest by the motor eventually stalling because of accumulated error in the phase?
It would typically take a few thousand turns.
not much on a spindle
But it is probably better to have scale and poles as seperate inputs, then do the division _after_ the modulo.
Yes first mod the encoder with encoder counts/rev then scale
I need to patch that soon, there is a guy out there about to use it.
so have counts-per-rev and poles as two different parameters
counts-per-rev always integer
well, poles always integer too I suppose
I want to use a monopole motor!
andypugh: do you know 2 vs 3 poles in some other way?
I thought maybe it was in the winding table somehow (implicitly)..
bldc_sine is spectacularly simple.
incidentally my sim session is up to about line 210k milling second.ngc..
the backplot length is way too short to show the whole thing
and my semi-real mill finished it
psha: what did you make?
semi-real means it has one real stepper motor laying near computer :)
you could make a ... circle cutter
(not a very good one)
at least i created excelent neighbors disturber :)
with driver division 2 and laying on the table it's very loud
yep that's a nice "feature" of stepper motors
truly speaking i was frightened when i've managed to control it from emc2
it jumps on the table surprisingly
and since my table is made from plywood it's greate resonator
jepler: very cool
(pid patch on devel list)
I'll happly test it tomorrow
micges: I'm eager to hear your results
hopefully it turns out to be real
few days ago I've noticed same problem as jelson
we will see
I am looking at how stepconf works.
Especially the "axis test" part.
Basically sending halcmds directly.
Does it have a way to iterate through hal pins and read their values?
My idea is that the 8i20 driver, in setup mode, would simply create a bunch of parameters that report out the register addresses of each module and sub module, then a python/glade configurator could set the eeprom values via the raw interface.
It seems pointless (and messy) to attempt to do it through the realtime driver code.
The alternative is probably a userspace program that duplicates most of the realtime driver but sits in a busy-loop looking for changes to parameters.
Writing parameters involves stopping the card and re-starting in a different mode, which is quite an awkward prospect in the realtime thread.