Back
[08:23:19] <jepler> anyone know offhand whether in fall 2013 we were still trying to keep master branch compatible with ubuntu 8.04?
[08:27:58] <archivist> I think that is in my bot logs
[08:29:12] <jepler> yeah I should take a look in my own logs. I know the dates we would have been talking about it: october 6/7 2013
[08:29:21] <jepler> aa08fad Avoid use of C++11 feature to initialize arrays and aggregates
[08:29:21] <jepler> c8ea07d interp/setup_struct: constructor definition
[08:32:15] <archivist> http://meetlog.archivist.info/meeting.php?id=201308
[08:32:24] <jepler> thanks
[08:33:50] <archivist> I remembered something being discussed :)
[08:37:06] <jepler> good memory
[08:37:43] <jepler> let's see what buildbot thinks of this
[08:37:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/braced-init 3a2a5c8 06linuxcnc 10src/configure.in configure: make c++11 mandatory * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3a2a5c8
[08:37:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/braced-init 1184113 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc interp: Use C++11 initializer-lists * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1184113
[08:38:02] <archivist> wend and searched for the version number, everybody was using the name!
[08:38:03] <jepler> maybe after just 1 1/2 years I figured out what was wrong with the very original code :-P
[08:38:06] <archivist> went
[08:38:27] <jepler> ta
[08:38:40] <archivist> I have bugs that lie around for years too :)
[08:43:24] <linuxcnc-build> build #3125 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3125 blamelist: Jeff Epler <jepler@unpythonic.net>
[08:44:43] <linuxcnc-build> build #3125 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3125 blamelist: Jeff Epler <jepler@unpythonic.net>
[08:44:53] <linuxcnc-build> build #3125 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3125 blamelist: Jeff Epler <jepler@unpythonic.net>
[09:06:31] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 --revision v2.6.8 0000.checkin
[09:06:36] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[09:09:06] <jepler> kaboom
[09:09:38] <jepler> emc/rs274ngc/interp_setup.cc:175: error: bad array initializer
[09:09:40] <jepler> well so much for that
[09:10:21] <linuxcnc-build> build #3135 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3135 blamelist: Jeff Epler <jepler@unpythonic.net>
[09:10:22] <linuxcnc-build> build forced [ETA 45m40s]
[09:10:22] <linuxcnc-build> I'll give a shout when the build finishes
[09:22:04] <jepler> hmm and that diagnostic option doesn't do what I thought it did
[09:49:16] <KGB-linuxcnc> 05jepler/braced-init 1184113 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1184113
[09:49:37] <jepler> oh well, looks like C++11 support is still not at the necessary level in our oldest platform
[09:55:57] <linuxcnc-build> Hey! build 0000.checkin #3136 is complete: Success [3build successful]
[09:55:57] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3136
[09:57:21] <seb_kuzminsky> jepler: bummer
[10:19:31] <jepler> why would you think that someone can and will explain to you why each and every line of source code is written as it is?
[10:19:50] <cradek> oh is he doing it again?
[10:20:00] <jepler> I have one in my personal e-mail today
[10:20:32] <archivist> read the code comment!
[10:21:52] <cradek> I can't decide whether I think that's worse than the whole devel list
[10:22:16] <archivist> I think it is worse,
[10:22:49] <jepler> sigh
[10:23:00] <jepler> I shouldn't have said anything
[10:23:33] <archivist> I think some expect too much hand holding
[10:37:41] <pcw_home> It is a bit of an question why the trajectory period is different that the servo thread rate
[10:37:43] <pcw_home> maybe at one time there was not enough CPU to run the TP at the servo thread rate
[10:49:06] <jepler> yes, I think that was the reason, particularly with nontrivkins. but never in Linux CNC 2 have they actually been in separate threads so I don't think it helps anything.
[10:53:18] <archivist> it is a bit like the resolution of numbers question that has been nagging me for eons
http://www.collection.archivist.info/archive/DJCPD/PD/2014/2014_09_28_Ford_speedo_gears/IMG_1837.JPG see left gear, it is helical and should not be
[10:54:38] <archivist> I put extra encoders on the machine to diagnose and they said no problem
[11:03:42] <cradek> archivist: weird
[11:15:53] <pcw_home> Also in the category of questions I'm to lazy to read to read the source code and figure out myself:
[11:15:54] <pcw_home> Is the Cartesian velocity pin of motion accurate enough to drive a raster clock gen for multi-axis raster
[11:15:56] <pcw_home> "painting" hardware?
[11:17:23] <jepler> I've always supposed that clocking from the step pin or encoder count would be better
[11:18:22] <jepler> to modulate the brightness during accel/decel, no idea
[11:19:04] <jepler> .. unless you need to go right to the edge of your travel, just budget enough lead in distance to be at speed
[11:19:07] <pcw_home> yeah for a simple 1 axis raster than makes sense
[11:20:17] <jepler> "multi axis" so that you can mount the work, measure its angle, and rotate the coordinate system to match?
[11:20:59] <jepler> I guess I'd resample the source image in that case so it was still a 1-axis problem
[11:21:08] <pcw_home> well imagine "painting" a raster on a complex surface
[11:22:01] <jepler> the angle of the surface would have to figure into it too
[11:25:00] <jepler> If you're putting the outlines of the continents on a hemisphere with a 3-axis system, to get the same amount of burn near the edge (equator) you need a different feed rate than at the middle (pole)
[11:27:25] <pcw_home> Right. I'm just trying to see if theres a more universal way of doing this than a rather hardwired
[11:27:27] <pcw_home> raster FIFO clock from rate multiplied (X,Y,Z encoder/stepgen)
[11:28:05] <jepler> if you've got a spare stepgen you can run it with the clock using a spare axis letter (like extruders do)
[11:31:19] <pcw_home> well the raster hardware is basically a stepgen that clocks as shift register that loaded from a 32 bit wide FIFO
[11:31:20] <pcw_home> (slow video basically)
[11:34:56] <jepler> I'm surprised that 32 bits wide is enough, but a little math shows me that if you fill the fifo every ms that still gets you >2m/s at 300dpi
[11:50:28] <pcw_home> for non diode lasers the maximum modulation frequency is not that high anyway
[11:50:29] <pcw_home> also even with a diode laser at say 10 IPS, a 16 deep 32 wide FIFO 1/2 used gives 256 bits/ms or
[11:50:31] <pcw_home> ~1/25000 dot size so good enough...
[11:54:05] <pcw_home> Luckily variable write sizes (for FIFO loading) are doable with hm2_eth
[11:54:06] <pcw_home> (unlike variable read sizes)
[15:22:57] <seb_kuzminsky> uploading 2.6.8 now
[15:23:01] <seb_kuzminsky> announcement tonight
[15:23:04] <cradek> yay!
[15:23:07] <seb_kuzminsky> :-)
[15:23:10] * cradek dances around the bonfire
[15:24:08] <jepler> seb_kuzminsky: thank you
[15:38:30] <skunksleep> Yay!
[15:54:20] <JT-Shop> Yippie
[17:07:43] <andypugh> Nearly every sample config contains “ #HALCMD = save neta”
[17:08:15] <andypugh> What would that actually do if uncommented? And is there a good reason for it to be there?
[17:25:16] <micges> it saves all nets in hal along with arrows
[17:25:59] <andypugh> OK, but does having it in the sample configs add anything?
[17:26:17] <andypugh> (Especially with no explanatory comment)
[17:27:01] <micges> no, I think its just leftover
[17:38:17] <cradek> I don't think that has ever been a useful thing to do
[17:38:45] <andypugh> cradek: Yes, in a sample config you alreay gave the HAL
[17:42:00] <cradek> I can almost imagine setting up all your hal connections interactively and then saving it, instead of editing a hal file. but to have linuxcnc save it every time? I don't get that.
[17:43:07] <cradek> bbl
[17:43:34] <andypugh> Yes, it’s a potentially useful thing, but not by default in a sample config
[17:48:07] <micges> agree
[17:53:01] <archivist> pcw_home, if it was a spray painting thing the you also have time of flight :)
[17:56:14] <archivist> in printers we varied the delay left/right to get verticals to align
[18:58:09] <Tom_itx> another potentially useful thing would be having configure recognize more sections in the ini like [SPINDLE] or other things that could use tuning parameters besides [AXIS_x]
[19:20:48] <andypugh> I can’t help feeling that the authors of Vismacj never intended anyone else to use it.
[19:20:58] <andypugh> (Vismach, that is)
[19:21:59] <andypugh> The documentation seems to basically say “look at the source code, if you couldn’t hav written it yourself, then you are unworthy to use it"
[19:25:27] <Tom_itx> maybe a silly question but using the 'near' component for spindle speed, with rigid tapping after the spindle reverses to retract does it still take effect or does the G33.1 override that?
[19:26:35] <andypugh> What is the “near” component connected to?
[19:27:30] <Tom_itx> hm2 encoder velocity
[19:27:34] <andypugh> I don’t think that G33.1 stops for anything.
[19:27:52] <andypugh> No, I meant what is the output used for?
[19:28:18] <Tom_itx> so the spindle will reach a designated speed before the axis moves
[19:28:41] <Tom_itx> instead of spinning up partway thru a cut
[19:28:54] <andypugh> No, I meant, what is the output connected to?
[19:29:11] <Tom_itx> motion.spindle-at-speed
[19:29:45] <andypugh> motion.spindle-at-speed IN BIT
[19:29:45] <andypugh> Motion will pause until this pin is TRUE, under the following conditions: before the first feed move after each spindle start or speed change; before the start of every chain of spindle-synchronized moves; and if in CSS mode, at every rapid->feed transition.
[19:30:21] <Tom_itx> so just at the start of the sync move
[19:30:34] <Tom_itx> which makes sense
[19:30:55] <andypugh> So, motion will wait at the start of G33.1, but stopping at the reversal would quickly become expensive.
[19:31:07] <Tom_itx> exactly
[19:31:09] <andypugh> Time to leave.
[20:35:43] <cradek> tinkerer: when you load pluto_servo does the board's led turn off?
[20:36:24] <tinkerer> cradek: yep
[20:36:50] <cradek> I took the box apart so I can see that led now
[20:37:03] <cradek> it does not turn off, even though pluto_servo thinks it loads
[20:37:14] <cradek> (with some ioaddr= options and not others)
[20:37:26] <cradek> usually it says "can't communicate with the board after sending firmware"
[20:37:35] <tinkerer> with halrun?
[20:37:41] <cradek> yes
[20:37:55] <cradek> halrun -I; loadrt pluto_servo ioaddr=0 (or other ioaddr= things)
[20:39:19] <tinkerer> ok, this means that the fw will not be loaded
[20:39:52] <tinkerer> do tou use a cable?
[20:39:56] <tinkerer> you
[20:40:05] <cradek> I have tried three cables
[20:40:14] <cradek> I am using the one that works with the old pc
[20:40:17] <tinkerer> try it without
[20:40:24] <cradek> can't, unfortunately
[20:40:28] <cradek> but the cable is known good
[20:40:50] <tinkerer> may be the cable but not the parport
[20:41:21] <cradek> I don't understand how that could be, if it works with the other pc
[20:41:48] <tinkerer> the other pc use the same parport card?
[20:41:56] <cradek> no
[20:42:10] <cradek> the old pc has a motherboard parallel port that works with this pluto and parallel cable
[20:42:30] <cradek> I changed the pc; this new pc has the sun1888 card; I left the same working cable
[20:42:51] <tinkerer> thats the reason
[20:43:10] <cradek> sorry - what is the reason?
[20:43:23] <tinkerer> different parport
[20:44:10] <tinkerer> different electrical properties
[20:45:19] <tinkerer> i have here a pc with onboard parport which works well
[20:45:35] <cradek> yes certainly could be
[20:45:53] <cradek> the pluto is well known to work with some parports and not others
[20:46:23] <tinkerer> but when i use a pci-card on the same pc it works sometimes
[20:46:34] <cradek> 7?? years ago we had some at emc-fest, in the days when we all had parports, we tried it on many and it worked on just a few
[20:46:41] <tinkerer> very randomly
[20:46:56] <cradek> yeah
[20:47:11] <tinkerer> I've a idea
[20:47:33] <tinkerer> i will test it in the next days
[20:48:26] <tinkerer> i will change the pullups on the pci-parport
[20:48:58] <cradek> hmm
[20:49:05] <cradek> I could maybe get a scope probe in here
[20:49:20] <cradek> it would tell me if the parport works at all
[20:49:29] <cradek> and maybe tell us something about pullups etc
[20:50:32] <tinkerer> they are mostly 4.7k
[20:51:50] <tinkerer> i will test it with the half value
[20:55:10] <tinkerer> with the scope watch the pin 1 and 2 of the parport at the fpga programming phase
[20:55:40] <cradek> at pin 2 I'm getting 5v swing during the programming attempt
[20:56:34] <tinkerer> pin 1 is the clock and pin 2 is the data
[20:56:54] <tinkerer> only on pin2?
[20:57:20] <cradek> also pin 1
[20:57:28] <cradek> only one hand :-)
[20:57:55] <tinkerer> ;)
[20:58:16] <cradek> let me try to get 1 & 2
[21:00:19] <tinkerer> could you a little bit more specify the word swing? ;)
[21:02:05] <tinkerer> like a sine or a rectangle
[21:04:27] <cradek> peak to peak is 5v
[21:04:32] <cradek> pin 2 has sharp corners
[21:04:35] <cradek> pin 1 looks like crap
[21:04:42] <cradek> one minute, I'll take a photo
[21:07:30] <cradek> http://timeguy.com/cradek-files/emc/pluto-pin1top-pin2bottom.jpg
[21:08:15] <cradek> does it program on rising or falling pin 1 clock?
[21:08:26] <cradek> rise looks terrible
[21:08:44] <tinkerer> yes, this is the pullup
[21:08:51] <tinkerer> to large
[21:09:51] <cradek> maybe should add extra pullup resistors on the pluto
[21:10:30] <cradek> what pins would need it? 2-9 are probably ok
[21:13:02] <tinkerer> try it first with pin1 to test the programming
[21:14:44] <cradek> http://timeguy.com/cradek-files/emc/pluto-pin1clock.jpg
[21:15:09] <cradek> only gets to 3.6 volts
[21:15:38] <tinkerer> yes, the pluto works with 3.3v
[21:17:04] <cradek> so you think add pin1 pullup to +5?
[21:23:10] <cradek> pcw_home: don't miss this study of crappy hardware that I'm using instead of yours :-)
[21:32:38] <tinkerer> cradek: how fast is your pc? (mhz)
[21:32:46] <cradek> added 2.2k pullup to +5 on pin 1
[21:32:58] <cradek> still does not program successfully but rise time is much better, and it goes to 4.8v now
[21:33:22] <cradek> new pc is 1800 MHz
[21:33:24] <tinkerer> 2.2k is to low
[21:33:29] ChanServ changed topic of
#linuxcnc-devel to:
http://linuxcnc.org | Latest release: 2.6.8 | (this channel is logged by the zlog robot)
[21:33:33] <seb_kuzminsky> woo
[21:33:35] <cradek> seb_kuzminsky: yay!
[21:33:41] <tinkerer> it's parallel with the 4.7k
[21:33:41] <seb_kuzminsky> i remembered this time!
[21:34:19] <cradek> which direction do you mean by too low
[21:34:48] <tinkerer> the right one.. ;)
[21:35:27] <tinkerer> too low
[21:35:35] <tinkerer> it was a typo
[21:36:09] <cradek> http://timeguy.com/cradek-files/emc/pluto-pin1clock-2k2pullup+5.jpg
[21:36:14] <tinkerer> you can kill the pluto
[21:36:14] <cradek> it looks a lot better now
[21:36:24] <cradek> what resistor do you think I should use?
[21:37:37] <tinkerer> could you change the pluto driver?
[21:37:56] <cradek> in linuxcnc? sure
[21:38:29] <tinkerer> there are lines :
[21:38:32] <tinkerer> // pull the reset low -- bit 2 of Control register
[21:38:32] <tinkerer> // keep it low 2 microseconds
[21:38:32] <tinkerer> for(i=0; i<4; i++) outb(0, ioaddr+2);
[21:39:05] <tinkerer> maybe the timing is too fast
[21:39:38] <cradek> hm yes maybe that is an unreliable way to do time delay
[21:39:55] <tinkerer> try doubling the values
[21:39:56] <cradek> if I know which pin, I could time it
[21:40:09] <tinkerer> yes u r right :)
[21:40:11] <cradek> which pin should have this 2us and 10us?
[21:40:47] <seb_kuzminsky> aahhh
[21:41:17] <seb_kuzminsky> i put a bow an all the work everyone else did for 2.6.8 and send an email to the list, and i get all the glory
[21:41:57] <cradek> heh :-)
[21:42:07] <cradek> it's ok, there's plenty of glory for all of us, we can share
[21:42:14] * seb_kuzminsky rubs hands together and cackles
[21:42:30] <cradek> it'd be glorious if you fixed my pluto
[21:42:40] <cradek> actually I can think of a lot of glorious things
[21:43:23] <Tom_itx> is that what was to be 2.7 or are you still holding 2.7?
[21:43:40] <tinkerer> seb: thats the burden of responsibility :)
[21:46:39] <cradek> tinkerer: increased delay does not help
[21:47:15] <tinkerer> there is another delay...
[21:47:15] <tinkerer> // Now program the device...
[21:47:15] <tinkerer> for(byte = 0; byte < FIRMWARE_SIZE; byte++) {
[21:47:15] <tinkerer> for(bit = 0; bit < 8; bit++) {
[21:47:15] <tinkerer> int v = firmware[byte] & (1<<bit);
[21:47:15] <tinkerer> if(v) outb(0xff, ioaddr); else outb(0, ioaddr);
[21:47:16] <tinkerer> outb(0|4, ioaddr+2);
[21:47:16] <tinkerer> outb(1|4, ioaddr+2);
[21:47:17] <tinkerer> outb(0|4, ioaddr+2);
[21:47:17] <tinkerer> }
[21:47:18] <tinkerer> }
[21:48:37] <cradek> I changed each of those outbs to 4 each
[21:48:58] <cradek> I confirmed that the clock is much slower now
[21:49:03] <tinkerer> ok
[21:49:10] <tinkerer> hmmm
[21:49:32] <cradek> 12us per clock; originally was about 3.5us in
http://timeguy.com/cradek-files/emc/pluto-pin1clock-2k2pullup+5.jpg
[21:49:51] <cradek> I have not checked the reset line
[21:50:01] <cradek> do you know which pin I should check?
[21:50:55] <cradek> I multiplied the reset time delays by 10 (40 and 200 outbs)
[21:51:17] <Tom_itx> does 2.8.6 support hm2 ethernet?
[21:51:30] <tinkerer> Data2 pin4
[21:51:44] <cradek> db25 pin 4?
[21:52:06] <cradek> ok checking
[21:52:15] <cradek> (bet it is ok because 2-9 are strong)
[21:54:38] <cradek> pin 4 goes high 5us, low 15us, high 15us, then low
[21:55:08] <skunkworks> Tom_itx: 2.8.6?
[21:55:21] <Tom_itx> err 2.6.8
[21:55:23] <skunkworks> 2.6.8? no
[21:56:49] <tinkerer> did you remove and replug the supply of the pluto before programming?
[22:00:48] <tinkerer> cradek: sorry, but i must consult my pillow its 4:30 after midnight... :)
[22:01:53] <tinkerer> next chance tomorrow, bye
[22:16:26] <cradek> tinkerer: good night, thank you :-)
[22:21:02] <cradek> reset is not pin 4, it must be pin 16
[22:21:18] <cradek> /Initialize, 0x4 on the control register
[22:23:16] <cradek> yes
[22:23:30] <cradek> it is low for 40us with my change (loop counts to 40)
[22:23:45] <cradek> the signal looks fine
[22:32:34] <cradek> with this resistor added, the signals all look fine, but it still doesn't program
[22:37:38] <cradek> I turned off computer and pluto before this last attempt, still same symptom, error from hal and the pluto LED is still dim
[22:51:58] <mozmck> How do I make linuxcnc power on when I toggle out of reset? I don't have any need for a 2 step process as is default.
[22:52:36] <cradek> wow, the pluto docs don't say how to send the firmware to it...?
[22:53:38] <cradek> mozmck: I think those controls are halui pins, so you could do something with ladder or whatever, to twiddle them how you want
[22:54:50] <cradek> I need a 3 channel scope :-/
[22:55:13] <Tom_itx> logic levels?
[22:55:20] <Tom_itx> get a saleae logic analizer
[22:55:26] <cradek> yeah
[22:55:27] <Tom_itx> alot cheaper than a scope
[22:55:30] <mozmck> I'm working on a gscreen based gui, and it uses hal_actions. I didn't know if there were INI settings that affected that.
[22:55:40] <Tom_itx> or one of those cheap knockoffs
[22:55:47] <Tom_itx> their software is pretty decent
[22:56:04] <mozmck> there are some cheaper logic analysers that look pretty nice.
[22:56:31] <mozmck> I have a Saleae 8 channel and it has been great - but did cost $150
[22:56:32] <Tom_itx> yeah some of those knockoffs will run the saleae software too
[22:56:40] <Tom_itx> same here
[22:56:50] <Tom_itx> but it paid for itself
[22:57:03] <cradek> looks like $219
[22:57:07] <mozmck> Some that I saw a while back looked a lot nicer than the saleae knockoffs.
[22:57:12] <Tom_itx> cradek that's the newer ones
[22:57:15] <cradek> kind of want
[22:57:57] <Tom_itx> and they're supposed to be bringing out their 10v analog ones
[22:58:05] <Tom_itx> dunno if that's happened yet or not
[22:59:26] <cradek> well darn, I thought fixing the obviously bad strobe signal would fix it
[22:59:43] <cradek> I wonder if it's bouncing and misprogramming
[23:06:11] <mozmck> the labtool from embeddedartists.com looks interesting - 11 channel logic analyzer, 2 channel scope, etc. open source
[23:17:39] <cradek> http://retired.beyondlogic.org/spp/parallel.htm says base+1 (status port) is read-only, but pluto_clear_error_register() writes to it
[23:45:18] <skunksleep> Wow..
http://www.shapeoko.com/forum/viewtopic.php?t=6103&p=47076
