Back
[00:19:06] <andypugh> If I have a branch off of an old Master, and want to update to a new Master, what's the process?
[00:19:47] <andypugh> I suspect not checkout master ; pull ; checkout branch?
[01:24:10] <jepler> * jepler has arrived in wichita. yay.
[01:28:56] <jepler> andypugh: in case you see this later, git fetch; git rebase origin/master
[01:29:51] <jepler> "git fetch" gets any updates to origin/master since you last fetched or pulled. "git rebase origin/master" will move your local commits from where they were to being on top of "origin/master". (if your branch was originally based on something else, like v2.4_branch, the result of this operation will be undesired!)
[02:18:54] <ries_> ries_ is now known as ries
[14:41:11] <skunkworks> mshaver: did you have a link to that cad program you where talking about?
[14:41:32] <mshaver> hold on a sec...
[14:44:07] <mshaver> http://www.mattshaver.com/setupIcad.exe
[14:44:26] <mshaver> the password at installation time is 'madison'
[14:44:33] <skunkworks> mshaver: thanks a lot!
[14:45:11] <mshaver> check your wine version -I have 1.01, later version gave me trouble a while back
[14:45:39] <skunkworks> ok
[14:45:48] <mshaver> if you can't get it going, I'll help - I've been using this for years & years now
[14:46:37] <mshaver> skunkworks: What we really need to do is to get Heeks to make an acad compatible command line!
[14:47:11] <skunkworks> yes!
[14:47:16] <mshaver> the we can type 'line' and get back the comfortable 'From point:'
[14:47:36] <skunkworks> Like I say - I have been corupted by the fact that autocad was my first real cad program.
[14:48:05] <mshaver> me too - 1987 - it's probably too late for me to change now
[14:48:24] <archivist> grow out of acad!
[14:48:30] <skunkworks> heh - I started with acad 11 probably around 92
[14:48:42] <mshaver> 2.6 for dos
[14:49:07] <skunkworks> (actually my first real paying job)
[14:49:15] <mshaver> archivist: I'd love to - but the rest of the engineering world insists on it
[14:49:28] <archivist> I hated acad and when I got to try solid edge and solidworks I never looked back
[14:50:00] <skunkworks> I can draw simple tool paths in acad so quick it hurts for me to change.
[14:50:19] <mshaver> yes, and a lot of the firms I work with use this now - but it's too much $$$ for me personally & it's Win only
[14:59:49] <cblack> I started working on a schematic like program to visually configure the HAL. Here's a screenshot so far.. anyone interested in helping out?
[14:59:53] <cblack> http://www.powerautomation.net/mainpage/images/stories/HalSchematic.png
[15:03:35] <skunkworks> someone had did a schematic drawer within eagle..
[15:03:39] <mshaver> cblack: That's really nice! Is it a "from scratch" program specifically for this purpose, or an adaptation of an existing EDA tool?
[15:04:16] <cblack> From scratch...made for Emc from ground up...
[15:04:27] <skunkworks> wow - neat!
[15:04:39] <cblack> Still needs lots of work.
[15:05:01] <mshaver> so, uh.. Can I try it! Can I! Can I! Can I! Can I! Can I! Huh?
[15:06:16] <cblack> Sure. It uses Qt, dono if just the binary will work... might have to compile
[15:08:36] <mshaver> I can try to get it to compile on my Lucid system
[15:10:31] <cblack> I'll upload it in a sec.
[15:19:35] <cblack> http://www.powerautomation.net/download/
[15:19:59] <SWPLinux> cblack: cool stuff!
[15:20:21] <cblack> It's buggy as hell and doesn't do a lot, but it's a start
[15:20:35] <SWPLinux> have you thought about how to keep the components in sync (between the actual source and the GUI configurator)?
[15:24:35] <cblack> If it has to read an old hal file and keep them in sync it gets really tricky. I was planning on forcing the user to recreate there entire config in the gui and then export the .hal file so there is no syncing.. Might have mixed views on that tho
[15:27:29] <SWPLinux> I guess I was thinking more about how to make a configuration on a machine that doesn't have the hardware attached (so you can't load the drivers)
[15:27:32] <cblack> As for the components that create different pins on loading, I was thinking about using an scipting which will create the component based on the arguments.
[15:27:37] <SWPLinux> or in sim even
[15:39:31] <cblack> Not entirely sure how I'm going to tackle all this yet. You should be able to recreate core_sim.hal simulated_home.hal and all the other sim components in the gui which will then export a proper .hal file..
[15:40:02] <cblack> It's some of the hardware components that don't stay constant that are going to be trouble..
[15:41:14] <mshaver> binary runs for me after installing libqt4-xml
[15:41:26] <cblack> Cool..
[15:43:34] <cblack> It's a little too big of a project to take on alone. but think it would really help newbies.. Wraping your head around a .hal text file can be fun at times.
[15:44:28] <cblack> mshaver: Did the docs show up when you click on a component?
[15:44:38] <mshaver> so, I can't really do anything, like place a component on the canvas
[15:44:44] <mshaver> no
[15:45:33] <cblack> You can connect pins with the line tool at the top.
[15:45:33] <mshaver> the UI comes up, but pointing, clicking, double clicking doesn't do anything
[15:45:52] <mshaver> how do I get something on the canvas?
[15:46:12] <cblack> Click one of the components on the left, then click on the canvas
[15:46:25] <mshaver> ah! ok!
[15:47:54] <mshaver> it all seems to work, but I cant connect a single output to multiple inputs
[15:48:42] <mshaver> no, wait, it works if I satrt with an unconnected pin
[15:48:46] <mshaver> start
[15:49:27] <cblack> I still have to make it so the wires arn't so hard to click.
[15:49:38] <cblack> right click a wire to break it.
[15:49:38] <mshaver> I assume the colors of the pins relate to their type - in, out, bidir maybe?
[15:49:42] <cblack> yes.
[15:51:01] <mshaver> segfaulted on deleting a wire - but really cool!
[15:51:12] <cblack> yeah it's a start..
[15:51:56] <mshaver> parsing existing hal configs will be tough
[15:52:29] <mshaver> oh, no docs show up when a comp is selected for me
[15:52:50] <cblack> You need man2html and the path is hardcoded right now.
[15:54:18] <cblack> Have you ever used qt?
[16:02:13] <mshaver> not as a programmer - my opinion is that it is very pretty, probably the prettiest widget set of all, but too big and too encumbered by the controversy over it's license model that occurred early on - personally, whatever its technical merits, I would never use it for anything unless it was specifically required by a customer
[16:05:06] <cblack> Yeah fair point. I really started using it because it has just about everything you ever need but mainly it's still cross platform.
[16:16:42] <mshaver> it's a _great_ toolkit, plus cross platform which I value highly - it will be interesting to see where it goes now that nokia owns it
[16:18:08] <cblack> Yeah, at least it's a toolkit thats going to keep going for quite a few years..
[16:20:27] <psha> greetings to buildbot's shepherd!
[16:21:09] <seb_kuzminsky> heh
[17:22:16] <JT-Work_> JT-Work_ is now known as JT-Work
[17:29:46] <jepler> micges: I am sorry that I didn't review your M61 patch right away. do you realize that you pushed it to v2.4_branch?
[17:57:34] <jepler> micges: anyway, the patch is wrong, beacuse the load_tool function takes a "pocket" number, not a tool number. (and on nonrandom machines, the "pocket" isn't the P number either, it's related to the order in the tbl file and that's all)
[17:58:10] <jepler> so if you have the first line of your .tbl as T2 and the second as T1 ... then M61 Q2 will actually load T1!
[17:58:20] <jepler> * jepler reverts it for now
[17:59:20] <CIA-2> EMC: 03jepler 07v2.4_branch * rfcb9870c8155 10/src/emc/iotask/ioControl.cc: Revert "iotask: Fix M61 Qn not loading tool in toolTable[0]"
[18:10:31] <cradek> micges: which sample config is the one that's set up for ja3?
[18:13:24] <cradek> micges: with sim/axis. I'm getting velocity 1 and low acceleration (also 1?) but the joint vel/acc are higher in the ini
[18:23:01] <skunkworks> cradek: what are you driving the gantry with?
[18:52:01] <cradek> a little mesa 7i30
[18:52:52] <cradek> it's enough to move the motors, but not much more
[18:53:15] <cradek> bbl
[20:28:05] <andypugh> is there a preferred name for a configuration modparam? I have noticed that they tend to be rather variable from component to component
[20:33:02] <cradek> do you mean for a count?
[20:41:51] <seb_kuzminsky> hi andy
[20:49:56] <CIA-2> EMC: 03cradek 07joints_axes3 * ra2e2807acd83 10/src/emc/motion/motion.c: fix typo in index-enable pin name
[21:20:07] <micges> jepler: sorry didn't notice that problem
[21:21:12] <andypugh> No, I want a bit-flag to turn on/off hall sensors, encoder, index, explicit offset inputs and bit/float 3/6 outputs.
[21:22:24] <andypugh> How's the weather in Wichita?
[21:24:48] <micges> cradek: use sim/gantry_mm config
[21:33:19] <cradek> micges: I notice the jog speed slider doesn't work
[21:34:08] <micges> I know
[21:34:34] <jepler> andypugh: rainy and cold
[21:35:35] <andypugh> For some reason I have always visualised Wichita as rainy and cold. I think I have only ever heard of it in the context of tornados/hurricaines.
[21:37:11] <cradek> micges: any idea why?
[21:38:36] <micges> simple_tp is harder to maintain
[21:38:47] <micges> I'm looking at it now
[21:38:53] <micges> give me few minutes
[21:40:52] <cradek> cool, thanks
[21:41:22] <micges> what are you using with ja3?
[21:41:54] <cradek> a little gantry machine I made for testing
[21:44:56] <micges> on fest?
[21:45:02] <cradek> yes
[21:55:20] <micges> cradek:
http://pastebin.com/rBVL4EAj
[21:55:54] <micges> it is quick fix to jog slider works, no idea what it will broke
[21:57:27] <cradek> thanks, Iwill try ti
[21:57:32] <cradek> wow, I fali at typing
[22:01:10] <cradek> micges: that didn't fix it...?
[22:01:41] <cradek> did you mean <
[22:03:33] <skunkworks> logger_dev: bookmark
[22:03:33] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-11-12.txt
[22:08:53] <CIA-2> EMC: 03seb 07master * r5a687d536090 10/docs/man/man9/hostmot2.9: Note defaults for pwmgen scale and pwm & pdm freq
[22:09:14] <skunkworks> seb_kuzminsky: you at the fest too?
[22:09:26] <seb_kuzminsky> i am festering
[22:09:31] <SWPLinux> EWWW
[22:09:34] <SWPLinux> oops
[22:09:36] <SWPLinux> ewww
[22:10:05] <skunkworks> yeck - I don't need that visual
[22:10:30] <skunkworks> ;)
[22:15:01] <micges> cradek: sorry I'm unable to locate this bug tonight
[22:15:44] <cradek> micges: if I change it to <, it works, still testing to see if it breaks anything else.
[22:15:49] <cradek> thanks for looking at it
[22:15:53] <micges> will look at this tomorrow morning so you can test it tomorrow morning
[22:16:09] <SWPLinux> does anyone remember the name of the Pascal-based reconfigurable EMC GUI that's in pseudo-development?
[22:16:13] <micges> weird
[22:16:25] <micges> mocca
[22:16:41] <SWPLinux> thanks
[22:19:48] <andypugh> SWPLinux:
http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,41/id,1813/lang,english/
[22:29:31] <psha> there was thread today on forum regarding USB FTDI chip in bitbang mode
[22:30:26] <psha> i've digged a bit into documentation and it seem that both chip and usb stack may live in 1ms (not us) limits
[22:30:44] <SWPLinux> correc
[22:30:46] <SWPLinux> t
[22:30:54] <psha> is there any problems with USB host interface that block using usb for control?
[22:31:10] <SWPLinux> and it's likely that there will be more than one cycle per "message"
[22:31:12] <SWPLinux> yes
[22:31:16] <SWPLinux> latency
[22:31:27] <psha> it's so high?
[22:31:52] <andypugh> I admit I have been egging that guy on.
[22:32:06] <SWPLinux> theoretically as low as 2 ms or so, practically (from what I've heard) more like 4 ms
[22:32:17] <andypugh> Currently the system runs from a VB package with a 20Hz refresh rate.
[22:32:29] <psha> it's rtt latency for sync command or just USB latency?
[22:32:41] <psha> andypugh: yes, i'm about that thread
[22:33:32] <andypugh> I suspect that there will be no latency at the drive end, there is no feedback, so if there is a way to send data to the USB port then it might actually work OK.
[22:34:07] <andypugh> It's a nasty drive that runs at a fixed step-rate anyway.
[22:34:17] <andypugh> (As far as I have been able to make out)
[22:34:34] <psha> that case is solvable even with userspace comp
[22:34:42] <psha> but i'm asking about a bit more general question
[22:34:43] <psha> why?
[22:35:13] <SWPLinux> ok, if you want "set it and forget it" mode, then USB could work
[22:35:13] <psha> FTDI chips are very cheap (FT232BM is sold for ~3$) and provides 8 pins for bitbang
[22:35:17] <SWPLinux> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc2HardwareDesign
[22:35:41] <SWPLinux> a USB microcontroller is about the same price, and provides 20 pins or so
[22:36:34] <psha> but you have to program it or at least find appropriate microcode
[22:36:54] <psha> and even then you'll get same problem as with FTDI chips in bitbang mode
[22:37:32] <SWPLinux> there are pretty good libraries for the AVR USB chips
[22:37:49] <SWPLinux> such as
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=ATMEGA8U2-AU-ND
[22:38:32] <psha> i know that programming microcontrollers is not that difficult but just strange for first time :)
[22:38:56] <SWPLinux> not much worse than programming an FTDI chip to act the way you want ;)
[22:39:00] <psha> i've 3 atmega chips waiting for spare time :)
[22:39:17] <SWPLinux> yeah, not much of that around
[22:39:23] <psha> but problem is not in chip configuration
[22:39:30] <psha> but in interacting with it from emc
[22:39:42] <SWPLinux> yep, that's a problem
[22:39:59] <cradek> emcAxisSetMinPositionLimit(2, -999999999999999967336168804116691273849533185806555472917961779471295845921727862608739868455469056.0000) returned 0
[22:40:36] <psha> i've digged a bit docs of linux usb stack and there are enought functions for async communication with usb devices
[22:40:38] <SWPLinux> there is a possibility using mostly existing code
[22:40:59] <SWPLinux> you would have to write the code that sends commands to the USB device, of course
[22:41:04] <psha> for slow devices you may just ensure that previous command was sent and only then continue sending
[22:41:09] <SWPLinux> and the USB device would have to be capable of buffering commands
[22:42:14] <SWPLinux> you could conceivably connect the motion controller joint position outputs to halsampler, and then pipe the halsampler output to your USB communication\ program
[22:42:24] <SWPLinux> -\
[22:43:49] <psha> that's too difficult :)
[22:44:11] <alex_joni> cradek: doesn't sound like such a "small" gantry then :P
[22:44:34] <SWPLinux> that's in Planck units
[22:45:15] <psha> i need first to win battle with my laziness, buy FT232BM and solder it :)
[22:45:52] <psha> and than it may be routed to parport's input pins and tested with halscope
[22:50:07] <mhaberler> a question on hal_manualtoolchange.py - is there any hard axis-related reason to use the nf and tcl stuff through rs274.options? or could it be just a wxPython app just as well?
[22:56:30] <SWPLinux> you can write a program in any language that can communicate with HAL, which at this point is C, python, tcl, and pascal (AFAIK)
[22:56:55] <psha> btw there is no guis using wxpython now?
[22:56:59] <psha> are
[22:57:07] <psha> so let it be first! :)
[22:57:14] <SWPLinux> since the program has to detect a change in the tool-change HAL pin, do its thing, and then signal emc that the change is done by changing another HAL pin (connected to tool-changed)
[22:57:46] <mhaberler> it's not about wx or not - I just find the nf.* / tcl stuff inpenetrable, so I'd rather avoid it if I can
[22:59:03] <psha> i'm not confident but on first look hal_manualtool is not tied to axis
[22:59:15] <psha> only common python code to load tcl code
[22:59:23] <SWPLinux> it's a standalone program
[22:59:49] <SWPLinux> the only requirement for a standalone program like it is that it must be a HAL-connected program
[23:00:53] <mhaberler> ok, thanks - so it could be a tab in a pyvcp or pyglade extension just as well. I just wasnt sure wether there's something going on at the tcl level where I fall off the cliff.
[23:03:35] <psha> sorry for dumb question but how hal_manualtoolchange prog looks like?
[23:09:53] <CIA-2> EMC: 03seb 07master * re89557d6d4e1 10/docs/man/man9/hostmot2.9: Oops, kilohertz is spelled kHz, not KHz
[23:18:27] <andypugh> KHz is a heating/cooling rate :-)
[23:18:54] <cradek> andypugh: we've already given him a hard enough time...
[23:21:00] <andypugh> psha: Can you rephrase the question?
[23:23:05] <andypugh> That's fun, you can run manualtoolchange in halrun through SSH. I just made a tool change dialog pop up on my Mac.
[23:23:43] <andypugh> halrun ; loadusr hal_manualtoolchange ; setp hal_manualtoolchange.change true
[23:26:14] <CIA-2> EMC: 03cradek 07joints_axes3 * r8e78b2d8453c 10/src/emc/motion/control.c: fix jog speed slider
[23:30:51] <andypugh> Is it OK to start a filename with a numeral?
[23:31:17] <cradek> yes
[23:31:32] <andypugh> Or perhaps m_8i20 or Mesa8i20 would work.
[23:34:19] <SWPLinux> someone should tell Peter to name his products with letters at the beginning
[23:52:23] <andypugh> I decided on mesa_8i20, similarly to pluto_stepper and opto_ac5
