Back
[03:47:48] <CIA-2> EMC: 03seb 07master * rdff6b257abcc 10/debian/ (control.in emc2.files.in rules.in): switch from dh_python (deprecated) to dh_pysupport
[13:30:19] <CIA-2> 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
[13:35:02] <SWPadnos> ineresting
[13:35:06] <SWPadnos> +t
[14:52:07] <Dave911> 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.
[14:52:08] <Dave911> 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.
[14:53:10] <skunkworks> Hi dave
[14:53:56] <skunkworks> I have to say - getting in deep with emc2 really has affirmed emc's awesomeness
[14:56:19] <cradek> but you keep finding stuff that doesn't work...
[14:56:28] <skunkworks> that is a good thing though
[14:56:43] <cradek> well I suppose they're all fixed now, though
[14:56:46] <skunkworks> make me feel like I am contributing in an odd way. ;)
[14:57:12] <skunkworks> I keep forgeting to try the estop/tool prep patch.
[14:57:23] <skunkworks> (on the actual machine)
[14:57:27] <psha> that's a way you 'pay' for emc :)
[14:58:26] <Dave911> >> has affirmed emc's awesomeness - I agree ... :-)
[15:01:14] <Dave911> Skunkworks: I have missed some of your recent vids but it sounds like your machine is doing very well.
[15:01:53] <skunkworks> getting there. :)
[15:02:28] <Dave911> Are there many more of those machines around still?
[15:03:01] <skunkworks> did you see
http://www.youtube.com/watch?v=KplU8hkI0AQ
[15:03:40] <skunkworks> Dave911: we have 2 (one we are taking apart for spares) I have only seen references to them in sales.
[15:03:43] <skunkworks> I don't know of any
[15:04:42] <Dave911> 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..
[15:05:07] <Dave911> I did see that video - very nice ..
[15:05:38] <skunkworks> Dave911: last one was this
http://www.youtube.com/watch?v=9xDPqFXo_5w&feature=mfu_in_order&playnext=1&videos=ul04bA3-tKk
[15:06:09] <skunkworks> oh sure - we are always on the lookout for a nice vmc cheap and local ;)
[15:18:38] <psha> cradek: why may axis fail during execution of big ngc file?
[15:18:58] <psha> i only imagine opengl and out-of-memory
[15:19:15] <psha> dmesg is clear, only line about segfault in axis process
[15:19:37] <psha> i've started same ngc file on my testbed machine with only stepper drive to check it against 10.04 release
[15:21:49] <cradek> I haven't seen that failure
[15:23:29] <psha> btw axis is eating 250M of memory on my testbed :)
[15:23:52] <psha> i suspect opengl issues since it tries to draw all paths
[15:23:56] <psha> and there are many of them
[15:24:12] <psha> 240k lines in ngc file
[15:26:14] <cradek> sure, it might be your opengl
[15:26:23] <micges> psha: can you paste it at filebin.ca ? I would like to test Axis with it
[15:27:00] <psha> uploading
[15:27:25] <psha> http://psha.org.ru/p/second.ngc.gz
[15:27:55] <psha> if it's really opengl issue then it may be good stress test :)
[15:28:14] <psha> but my D510M performing fine with it...
[15:35:11] <psha> micges: is it loading fine?
[15:35:15] <micges> yes
[15:35:23] <micges> 7 sec
[15:35:24] <psha> so it will work fine
[15:35:34] <micges> its eats 250mb of ram
[15:35:46] <psha> i've asked for details and it's reported to sometimes crush axis on load
[15:36:07] <psha> you have glx disabled or enabled?
[15:37:24] <micges> you mean graphic driver?
[15:38:18] <micges> I have software rendering only
[15:38:26] <psha> yes
[15:38:27] <psha> thanks
[15:38:34] <psha> i've reported back that it's opengl issue :)
[15:38:54] <cradek> loads fine for me too (using sim, nonrt kernel, nvidia binary driver)
[15:39:28] <psha> thanks a lot
[15:39:48] <cradek> pretty slo
[15:39:49] <cradek> w
[15:40:02] <cradek> you could put (AXIS,stop) magic comment to make AXIS stop generating preview
[15:40:02] <psha> i'll try to switch to software rendering on that machine
[15:41:04] <psha> but it'll be on thursday...
[15:41:22] <psha> when i'll bring new D510M replacement there
[15:42:03] <cradek> yuck, terrible gcode
[15:42:08] <cradek> circles are made of little lines
[15:42:10] <jepler> fine here. 240MB RES according to top.
[15:42:15] <jepler> also nvidia, sim..
[15:42:31] <cradek> 20442 cradek 20 0 271m 232m 17m S 15 23.2 1:59.56 axis
[15:43:11] <jepler> (and the preview isn't all that *useful* either... way too many lines to actually see anything)
[15:43:39] <psha> i'll try disabling AXIS preview too
[15:43:47] <psha> so i'll definitely know what happens
[15:44:00] <psha> thanks a lot for testing again
[15:48:09] <micges> psha: no issues with nvidia binary driver
[16:01:54] <jepler> apropos of nothing, the preview plot becomes more useful when drawn like this:
http://emergent.unpy.net/files/sandbox/preview-plot-alpha.png
[16:02:42] <micges> what did you do?
[16:03:21] <jepler> it uses an opengl blend mode
[16:05:17] <jepler> 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
[16:05:39] <jepler> before the shape was more or less a white blob, as I assume you saw
[16:05:46] <micges> yes
[16:05:53] <psha> beatiful :)
[16:06:48] <psha> and how blend mode may be enabled?
[16:07:05] <jepler> lib/python/rs274/glcanon.py | 42 ++++++++++++++++++++-----
[16:07:08] <jepler> src/emc/usr_intf/axis/extensions/emcmodule.cc | 6 ++-
[16:07:11] <jepler> 2 files changed, 38 insertions(+), 10 deletions(-)
[16:07:12] <jepler> 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)
[16:08:51] <psha> testing
[16:09:41] <cradek> how does it look with more normal programs?
[16:09:45] <jepler> cradek: darker
[16:10:10] <SWPadnos> you could increase (or make user-adjustable) the line width
[16:11:34] <cradek> could make alpha another view option
[16:12:14] <psha> 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
[16:12:57] <SWPadnos> very slick
[16:13:16] <cradek> that sure helps the torus preview...
[16:13:29] <cradek> wonder how badly it hurts software rendering?
[16:13:56] <jepler> I'm not sure.
[16:14:13] <jepler> now that I am thinking about it more, it might be closer to a wash
[16:15:23] <jepler> old pipeline is approximately: read depth buffer, compare computed branch, conditional branch, write depth buffer, write color buffer
[16:15:50] <jepler> s/compare computed branch/compare computed depth, conditional branch/
[16:16:03] <jepler> new pipeline is approximately: read color buffer, perform blend operation, write color buffer
[16:16:46] <jepler> compared to memory access, I think a little arithmetic like (a*b + c*d) >> 8 may be free
[16:17:45] <jepler> particularly if mesa is able to use mmx and/or sse
[16:18:36] <jepler> logger_dev: hanging in there?
[16:18:36] <jepler> I'm logging. Sorry, searching removed.
[16:22:02] <micges> indeed part looks much better
[16:22:33] <SWPadnos> I'd expect mesa to use SSE/MMX if available (I can't imagine it being usable without that)
[16:31:36] <jepler> yes, I think so
[16:32:31] <psha> so actual sw rendering is needed :)
[16:33:01] <SWPadnos> that's what mesa is :)
[16:33:13] <SWPadnos> it also works with hardware rendering
[16:33:18] <jepler> I am pretty sure any current accelerated opengl will accelerate this operation.
[16:33:33] <jepler> it's almost the most basic transparency effect
[16:33:45] <psha> i mean actual sw rendering tests are needed for this feature :)
[16:33:52] <jepler> oh, yes.
[16:33:53] <psha> falling asleep...
[16:35:11] <psha> i've tried xephyr but it refuses to work with ati fglrx driver
[16:35:37] <psha> and i have to use that fglrx at least for a month or two
[16:51:49] <skunkworks> that patch runs nice on my laptop - using whatever the default driver is for my ati card
[16:51:59] <andypugh> Do hal pins "know" that they are wired? (or can the driver figure it out?)
[16:52:37] <SWPadnos> you can test for a connection in your module
[16:52:50] <SWPadnos> I think
[16:53:01] <SWPadnos> like if (pin isn't pointing to dummy variable)
[16:53:11] <SWPadnos> but you may have to hold onto some extra data to do that
[16:53:13] <skunkworks> (not the fglrx closed source driver)
[16:53:15] <andypugh> I guess that has to happen in the realtime code?
[16:53:25] <SWPadnos> it would, but it shouldn't be necessary
[16:53:33] <SWPadnos> if it is, you probably have a design error :)
[16:53:53] <andypugh> I am considering merging the two bldc drivers.
[16:54:14] <andypugh> As the 8i20 sort-of wants a hybrid version.
[16:56:23] <andypugh> 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
[16:57:21] <andypugh> It is probably better to do it from the config string though.
[16:58:07] <jepler> 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
[16:58:29] <jepler> andypugh: if you'd be willing to continue working with the guy on the web bbs
[16:58:50] <andypugh> PCW replied on the forum that he will build one today.
[16:58:58] <jepler> ah ok
[16:59:18] <andypugh> But I guess it might as well be in the main firmware set too.
[16:59:23] <jepler> I didn't see that
[16:59:31] <SWPadnos> andypugh, I would do it from the config string, or have a mode pin/parameter
[17:00:11] <andypugh> I am not clear how the split between your firmware builds and PCWs builds works.
[17:01:24] <cradek> 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
[17:02:11] <cradek> you as a mesa user can use firmwares from either source or even build your own
[17:02:14] <andypugh> So the firmwares are logically identical, but philosophically distinct? :-)
[17:02:15] <cradek> (I don't know if that helps)
[17:02:52] <cradek> well I think we even agree on the philosophy
[17:04:03] <andypugh> In "Comp" does the "personality" string have to be called "personality"?
[17:04:23] <jepler> andypugh: at the moment, yes.
[17:05:34] <andypugh> 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)
[17:06:40] <jepler> andypugh: does this influence the pins/parameters your instances create, or something else?
[17:07:18] <andypugh> It influences the pins, yes.
[17:07:38] <andypugh> mode 1 might be encoder-onle, mode 2 hall-only and 3 would be both.
[17:07:58] <andypugh> And then you probably wouldn't create the hal pins that weren't used.
[17:08:37] <andypugh> Or I could write a bldc_hybrid comp to join the family.
[17:09:42] <jepler> so the only thing lacking is the ability to name the module parameter "config" instead of "personality"?
[17:11:05] <andypugh> I would probably be wanting to only have one parameter. (rather than a count and a personality)
[17:11:59] <jepler> you can use option count_function .. get_count() would look at the personality array and figure out how many were specified (e.g., nonzero)
[17:12:32] <andypugh> Am I guilty of not reading docs?
[17:12:39] <jepler> oh the docs are crummy
[17:13:34] <jepler> bbl, lunchtime
[17:13:50] <jepler> maybe it's not hard to add "personality with a different name", I'll look into it after I'm full of food
[17:14:07] <andypugh> I think option count might do.
[17:14:17] <andypugh> Let me experiment.
[18:10:17] <andypugh> 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
[18:16:18] <jepler> andypugh: that's for userspace components, which have an argc and argv
[18:16:32] <jepler> I don't think anybody's actually using comp for userspace components, though
[18:17:01] <jepler> 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)
[18:17:13] <jepler> .. but the performance with second.ngc and alpha rendering is still very good
[18:18:07] <andypugh> I am serioulsy considering writing a userspace comp for configuring the 8i20 EEPROM
[18:18:28] <jepler> how will that work? A userspace component can't access the hardware directly..
[18:18:52] <andypugh> I was hoping to twiddle the raw interface
[18:19:02] <jepler> I see. that makes sense.
[18:21:02] <andypugh> 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.
[18:21:35] <skunkworks> jepler: I didn;t notice any speed decrease.
[18:22:04] <skunkworks> how can I tell what I am using for video?
[18:22:58] <skunkworks> acellerated/hardware or not.
[18:23:07] <jepler> skunkworks: $ glxinfo | grep '^OpenGL'
[18:23:16] <jepler> .. if you have the glxinfo program installed
[18:25:06] <jepler> in the alpha rendering mode, it becomes unclear what parts of the preview plot are in front of the backplot
[18:25:56] <skunkworks_> OpenGL vendor string: Advanced Micro Devices, Inc.
[18:25:58] <skunkworks_> OpenGL renderer string: Mesa DRI R600 (RV730 9488) 20090101 TCL DRI2
[18:25:59] <skunkworks_> OpenGL version string: 1.5 Mesa 7.7.1
[18:26:01] <skunkworks_> OpenGL extensions:
[18:26:20] <jepler> that's accelerated.
[18:26:41] <skunkworks> ah
[18:26:50] <skunkworks> runs great :)
[18:27:32] <jepler> I'm not satisfied with how it looks combined with backplot.
http://emergent.unpy.net/files/sandbox/unclear.png
[18:28:23] <jepler> the red dome part in the backplot should be 'behind' the backplot, but it doesn't look like it is
[18:29:54] <skunkworks> that is a bit ugly
[18:31:09] <skunkworks> can you make the backplot line the same size as the preview - just red?
[18:35:13] <SWPadnos> aaahhhh. so much easier to trust the digital caliper when the numbers aren't flashing and faded :)
[18:37:36] <skunkworks> heh
[18:38:20] <psha> 1 pixel lines are better but not ideal
[18:39:08] <psha> btw what is DTG?
[18:39:25] <jepler> distance to go
[18:39:31] <jepler> the remaining distance in the current move
[18:40:20] <psha> thanks
[18:44:09] <psha> is blending used for backplot?
[18:46:36] <jepler> I'd have to refresh my memory about that
[18:47:55] <psha> with 1px lines it's only a bit better
[18:50:08] <psha> http://psha.org.ru/p/backplot-1px.png
[18:53:15] <skunkworks> that does look better though.
[18:58:54] <psha> reconnect :(
[19:05:46] <jepler> psha: do you happen to know what software generated this gcode (second.ngc)?
[19:07:07] <psha> i may ask
[19:07:18] <micges> by hand seems to me ;P
[19:08:29] <psha> micges: 20 enslaved citizens were writing it for a month!
[19:09:38] <micges> chinese i guess.
[19:11:34] <psha> tajiks are cheaper here...
[19:12:05] <micges> russia?
[19:12:11] <psha> yes :)
[19:12:58] <psha> here are many workers from asian ax-ussr republics
[19:13:08] <psha> at least here thay may found job
[19:13:30] <psha> nearly every family there have one or two members working in large cities here
[19:14:02] <psha> when my brother was on trip in tajik mountains he talked to lot of people
[19:14:49] <micges> I see
[19:15:14] <psha> and most of them have relatives working here
[19:16:14] <psha> 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
[19:17:08] <psha> and indeed it was open when he told
[19:17:18] <psha> 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
[19:49:37] <PCW> (I already made .bit and.pin files and posted them in the forum)
[19:52:23] <jepler> thank you PCW
[19:54:54] <micges> jepler: all those additional bit/pin files for cards supported by emc are stored somewhere?
[19:55:04] <micges> (index latch stuff and such)
[19:55:04] <PCW> Welcome
[19:56:30] <jepler> 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
[19:56:58] <jepler> everything I keep track of is in the hostmot2-firmware packages
[19:57:51] <andypugh> How long do files stay on Filebin for?
[19:58:10] <cradek> I think you can choose that
[19:58:20] <PCW> I think I selected a month
[19:58:31] <andypugh> That should catch him then.
[19:58:51] <micges> jepler: I see
[20:01:40] <andypugh> I think I spotted a problem today:
[20:01:42] <andypugh> bldc-sine.N.scale float rw (default: 512)
[20:01:42] <andypugh> 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.
[20:03:17] <andypugh> 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?
[20:03:58] <andypugh> Of course, it rather depends on how many complete revolutions the encoder does.
[20:04:09] <jepler> and this would manifest by the motor eventually stalling because of accumulated error in the phase?
[20:04:17] <PCW> Yep
[20:04:45] <andypugh> It would typically take a few thousand turns.
[20:05:04] <PCW> not much on a spindle
[20:05:15] <andypugh> But it is probably better to have scale and poles as seperate inputs, then do the division _after_ the modulo.
[20:06:07] <PCW> Yes first mod the encoder with encoder counts/rev then scale
[20:06:38] <andypugh> I need to patch that soon, there is a guy out there about to use it.
[20:06:45] <jepler> so have counts-per-rev and poles as two different parameters
[20:06:52] <jepler> counts-per-rev always integer
[20:06:59] <jepler> well, poles always integer too I suppose
[20:07:21] <andypugh> I want to use a monopole motor!
[20:07:30] <jepler> andypugh: do you know 2 vs 3 poles in some other way?
[20:07:40] <andypugh> No.
[20:07:58] <jepler> I thought maybe it was in the winding table somehow (implicitly)..
[20:08:24] <andypugh> bldc_sine is spectacularly simple.
[20:51:45] <jepler> incidentally my sim session is up to about line 210k milling second.ngc..
[20:52:00] <jepler> the backplot length is way too short to show the whole thing
[21:02:22] <psha> and my semi-real mill finished it
[21:02:40] <cradek> psha: what did you make?
[21:03:10] <psha> semi-real means it has one real stepper motor laying near computer :)
[21:03:21] <cradek> aha
[21:03:34] <cradek> you could make a ... circle cutter
[21:03:41] <cradek> (not a very good one)
[21:03:50] <psha> :))
[21:04:11] <psha> at least i created excelent neighbors disturber :)
[21:04:37] <psha> with driver division 2 and laying on the table it's very loud
[21:08:51] <cradek> yep that's a nice "feature" of stepper motors
[21:09:48] <psha> truly speaking i was frightened when i've managed to control it from emc2
[21:10:01] <jepler>
[21:10:12] <psha> it jumps on the table surprisingly
[21:11:04] <psha> and since my table is made from plywood it's greate resonator
[21:13:33] <cradek> bbl
[22:36:11] <micges> jepler: very cool
[22:36:34] <micges> (pid patch on devel list)
[22:36:42] <micges> I'll happly test it tomorrow
[22:40:27] <jepler> micges: I'm eager to hear your results
[22:40:41] <jepler> hopefully it turns out to be real
[22:40:51] <micges> maybe so
[22:41:09] <micges> few days ago I've noticed same problem as jelson
[22:42:00] <micges> we will see
[22:45:08] <micges> good night
[23:15:28] <skunkworks> jepler: Neat!
[23:18:47] <andypugh> I am looking at how stepconf works.
[23:19:10] <andypugh> Especially the "axis test" part.
[23:19:36] <andypugh> Basically sending halcmds directly.
[23:20:11] <andypugh> Does it have a way to iterate through hal pins and read their values?
[23:22:07] <andypugh> 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.
[23:22:35] <andypugh> It seems pointless (and messy) to attempt to do it through the realtime driver code.
[23:24:15] <andypugh> 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.
[23:26:36] <andypugh> Writing parameters involves stopping the card and re-starting in a different mode, which is quite an awkward prospect in the realtime thread.
