Back
[00:01:19] <jmkasunich> BigJohnT: not pretty I bet
[00:04:23] <BigJohnT> the dirt burns and makes a mess of the auger
[00:04:35] <BigJohnT> good thing the breaker worked
[00:05:16] <BigJohnT> and we told the yoyo's not to put the light pole there as we had a hv line running through there....
[00:24:29] <archivist> jepler further testing -t has to be a whole number 1 or 2
[00:25:43] <fenn> archivist: my idea was to just use the most basic function of gdepth (since you already know where the tool is) instead of doing full g-code and running through an interpreter (and requiring the emc interpreter etc)
[00:27:07] <archivist> fenn still useful for gcode testing solids
[00:27:10] <fenn> so you would write some python function like "import gdepth; import vcarve; gdepth(vcarve('foo'))"
[00:27:55] <fenn> gdepth.cut_along(...
[00:28:05] <archivist> except Im not a python person at the moment, i more comfotable with C
[00:28:39] <fenn> a very ugly hack would be to printf() python code and exec it :)
[00:28:50] <archivist> ew
[00:31:01] <archivist> I can see gdepth code merging with vismach models and seeing the virtual finished job on the virtual machine
[00:34:52] <DaViruz> is it possible to add some kind of time estmation in axis? that calculates total time for the job, and shows remaining time during the job
[00:34:56] <DaViruz> that would be very nice
[00:38:20] <DanielFalck> jepler: thanks for fixing gdepth- and archivist- thanks for getting jepler to fix it : )
[00:38:33] <DanielFalck> I forgot all about that script
[00:40:19] <dmess> hi all
[00:40:34] <archivist> it has the potential to take solid models and cut them
[00:41:21] <dmess> what help does it nee ti finish up
[00:41:38] <dmess> need to
[04:09:01] <cradek> I spent today rebuilding a carburetor - whee
[04:29:20] <PeterW> JMK: I'll send you a build log of 5I20 Hostmot2 tomorrow, got to do that at my windows machine at work...
[04:29:22] <PeterW> I20HostMot2.vhd is the correct top level file, you also need to associate the 5i20.ucf file with the build
[04:29:24] <PeterW> custom pinouts are all in the IDPrams.vhd file. 2 generics need to be changed in I20HostMot2 to select a new pinout
[04:29:46] <jmkasunich> oh, hi
[04:29:53] <PeterW> (IDParms.vhd)
[04:30:05] <PeterW> Hi JMK
[04:30:40] <jmkasunich> is there a .spec file involved in the process?
[04:31:06] <SWPadnos> a web search says that may be a ".ncf" file
[04:31:42] <PeterW> Not sure, I just use the GUI, but the log gives all the command line stuff run so should be a good start to command line make
[04:31:52] <jmkasunich> oh, cool
[04:31:57] <jmkasunich> that would be great
[04:32:30] <jmkasunich> in the IDParms.vhd file, do you just add another entry for every custom pinout?
[04:32:40] <PeterW> Changing pinouts could be a lot easier...
[04:32:54] <jmkasunich> two entries looks like:
[04:32:57] <jmkasunich> constant PinDesc_SVST4_4 : PinDescType :=(
[04:32:57] <jmkasunich> -- Base func sec unit sec func sec pin
[04:33:10] <jmkasunich> constant ModuleID_SVST4_4 : ModuleIDType :=(
[04:33:10] <jmkasunich> (WatchDogTag,x"00",ClockLowTag,x"01",WatchDogTimeAddr&PadT,WatchDogNumRegs,x"00",WatchDogMPBitMask),
[04:33:50] <PeterW> Yes just a modified pindesc and module desc if you change the number or type of functional units
[04:34:39] <jmkasunich> but IDParm doesn't get "changed", it just gets longer? and then somewhere you say which version you are building? or does it build them all?
[04:35:23] <jmkasunich> btw, cradek says you work all the time - but you weren't working Friday afternoon, I called to place an order
[04:35:41] <SWPadnos> slam!
[04:35:51] <PeterW> pindesc and module desc are specified in a generic at the top of i20hostmot2.vhd
[04:35:52] <jmkasunich> I'll call monday for that - gonna get a 7i40HV
[04:36:01] <SWPadnos> (as if Pete takes the orders anytway :) )
[04:36:09] <SWPadnos> -t
[04:36:22] <jmkasunich> I know - he works all the time, but he gives his employees a break
[04:36:49] <cradek> jmkasunich: switching the shoptask to servo?
[04:37:00] <jmkasunich> PeterW: this?
[04:37:03] <jmkasunich> ThePinDesc: PinDescType := PinDesc_JDosa66;
[04:37:03] <jmkasunich> TheModuleID: ModuleIDType := ModuleID_JDosa66;
[04:37:19] <PeterW> Actually noone worked at Mesa on Friday...
[04:37:19] <jmkasunich> cradek: nope (at least not right away)
[04:37:38] <jmkasunich> I got some of those ametek servos, and want to play over christmas break
[04:38:38] <PeterW> Yep. A better way for autobuillds would be to have a separete file for each pindesc-moduledesc pair and let the name be the filenames
[04:39:31] <jmkasunich> some of this is coming back to me now - when I was doing a makefile, I had to generate the .prj file by searching the .vhd for "use" statements
[04:41:56] <jmkasunich> PeterW: if you can send me a log, I'll start fresh tomorrow (it's 11:40 here, time to walk the dog and get some sleep)
[04:41:59] <jmkasunich> thanks for the help
[04:43:28] <PeterW> Welcome, and I'll do that first thing tomorrow
[04:43:57] <jmkasunich> I'll try to figure out a build procedure that works, and commit it into CVS (with lots of comments)
[04:44:44] <jmkasunich> Jeff apparently got the makefile working back in August, but the current vhdl in CVS dates from September and doesn't work with the makefile
[04:45:31] <PeterW> Also note that the source for all of Hostmot2 is the same, only the top level files are different for different card types
[04:45:55] <jmkasunich> right
[04:46:40] <jmkasunich> different cards = different top level, different configs within a card = different generic lines in the top level
[04:46:55] <PeterW> yes there were quite a few changes so that only the pindesc and module descs need to be changed to create a new configuration
[04:47:12] <PeterW> Yes
[04:47:22] <seb_kuzminsky> hi peter
[04:47:35] <PeterW> Hi Sebastian
[04:48:21] <jmkasunich> would it work to have one much shorter IDParm.vhd for each combo, and then just change the "use" line in the top level (or do some file renaming) to select which one to use, instead of having a huge IDParm with every combo ever used?
[04:49:19] <PeterW> Yes JMK, thats was what I was suggesting a few lines back...
[04:49:35] <jmkasunich> duh
[04:49:39] <jmkasunich> you can tell it's late
[04:50:02] <PeterW> Welll I didn't say IDParm...
[04:51:36] <PeterW> A Lot of this has just grown and needs a good rototilling...
[04:54:55] <dmess> anyone here play guitar?? Martin Packpacker's on sale
[04:56:01] <dmess> classical and steel stings available
[04:56:20] <jmkasunich> goodnight all
[04:56:53] <dmess> gn JMK
[05:07:22] <PeterW> 'nite all
[05:48:17] <ds3> arrg
[05:48:24] <ds3> camera keyhole distortions :(
[05:48:38] <JymmmEMC> ?
[05:48:54] <ds3> building a 3D scanner
[05:49:02] <JymmmEMC> ah
[05:49:14] <ds3> I can assemble 4 sides on the bottom but the top doesn't match
[05:51:55] <JymmmEMC> turn it sideways =)
[05:52:34] <ds3> heh
[05:53:01] <ds3> i think i can fix it by mounting the camera differently to avoid the keyhole distortionn
[05:53:47] <JymmmEMC> ok, turn the camera sideways =)
[13:45:45] <outside> outside is now known as outsidelt
[13:48:27] <outsidelt> hi.Q: why here is no axis "enable" pins in EMC?
[13:49:33] <fenn> there are
[13:50:33] <fenn> try: halcmd show pin *enable*
[13:51:59] <outsidelt> tried ubuntu-emc live cd - in config there were step, dir, some more, but no axis enable..
[13:53:08] <fenn> itconfigs/stepper/core_stepper.hal:net Xen axis.0.amp-enable-out => stepgen.0.enable
[13:53:41] <fenn> does yours not have this line?
[14:45:56] <jepler> outsideit may have meant pin assignments in stepconf (but I'm just guessing because he didn't give much information) There's a single amplifier enable, not one for each axis, because emc always enables all axes together.
[15:08:02] <alex_joni> jepler: carefull, cradek will make fun of your font :)
[15:21:17] <jepler> my font?
[15:21:27] <alex_joni> outsideit vs outsidelt
[15:21:47] <jepler> oh, hm.
[15:21:58] <jepler> my font is just fine, they're very distinct
[15:22:03] <jepler> perhaps he should make fun of my brain instead
[15:28:54] <alex_joni> I'm sure he won't :)
[15:29:03] <skunkworks> snow here!
[15:29:13] <alex_joni> nice
[15:29:34] <alex_joni>
[15:29:46] <alex_joni> odd connection issues
[15:31:41] <skunkworks> yeck
[15:49:54] <fenn> jepler: does this work for you?: git-clone git://git.unpy.net/stepconf.git
[15:50:11] <fenn> git.unpy.net[0: 206.222.212.218]: errno=Connection refused
[15:50:16] <alex_joni> he's not back from the split
[15:50:20] <fenn> oops
[15:50:52] <alex_joni> any reason you need that?
[15:51:03] <fenn> i was trying to clone the offs repo
[15:51:15] <alex_joni> ah.. not stepconf :)
[15:51:17] <fenn> stepconf is the example provided
[16:10:55] <alex_joni> hi ray