Back
[13:47:07] <alex_joni_> alex_joni_ is now known as alex_joni
[19:04:38] <alex_joni> * alex_joni yawns
[19:21:00] <SWPadnos> go to sleep then ;)
[19:21:40] <alex_joni> it's early ;)
[19:21:50] <alex_joni> SWPadnos: found a nice program today
[19:21:52] <SWPadnos> well - you were yawning
[19:21:56] <SWPadnos> which one?
[19:22:02] <alex_joni> yawning = bored ;)
[19:22:05] <SWPadnos> heh
[19:22:13] <alex_joni> I'll send you some screenshots
[19:22:17] <SWPadnos> ok
[19:22:27] <SWPadnos> do you follow the CNC-Toolkit Yahoo group?
[19:22:40] <alex_joni> nope
[19:23:18] <SWPadnos> ok - there's a discussion about 5 or 6 axis CNC controllers, I pointed out our favorite, EMC :)
[19:27:07] <SWPadnos> the trouble is, one guy is now asking about getting 5-axis CAM output on Linux
[19:27:17] <SWPadnos> of course, there's the problem of 3-axis CAM on Linux as well
[19:27:22] <SWPadnos> Hi Ray
[19:27:29] <alex_joni> only synergy comes to mind
[19:27:31] <alex_joni> hi ray
[19:27:32] <rayh> Hi Steven
[19:27:37] <rayh> Hi Alex.
[19:27:45] <SWPadnos> yeah - do you know the cost for the CAM portion of Synergy?
[19:28:21] <SWPadnos> let me paste in this email - it illustrates a problem (in perception at least) with emc:
[19:28:36] <SWPadnos> I looked at EMC a couple years ago when I was looking for a option to
[19:28:37] <SWPadnos> Flashcut. Went with Mach2. I hate all the problems with windows and
[19:28:39] <SWPadnos> would love to jump to the linux wagon but my problem is how do I
[19:28:40] <SWPadnos> create the toolpath in linux?
[19:28:42] <SWPadnos> Is there a Linux Gmax that will run Cnc toolkit? Or another option to
[19:28:44] <SWPadnos> create and minuplate models in linux? I know of blender but its about
[19:28:45] <SWPadnos> the most backwards of any software I have tried to use. Been in the
[19:28:47] <SWPadnos> windows world all my life.
[19:28:48] <SWPadnos> What do the emc users create there 3,4,5 and 6 axis continious
[19:28:50] <SWPadnos> contouring toolpaths in?
[19:28:52] <SWPadnos> Other than my router and quickbooks for me there is no reason to stay
[19:28:53] <SWPadnos> with windows.
[19:29:03] <SWPadnos> this is a response to a post of mine pointing out that emc can be made to work with a robot arm (given sufficient incentive :) )
[19:35:57] <SWPadnos> any ideas on how to respond?
[19:36:33] <alex_joni> synergy
[19:36:34] <alex_joni> does 5-axes CAM
[19:36:40] <alex_joni> but it's expensive
[19:36:47] <rayh> Yea. We build machine controls.
[19:36:47] <SWPadnos> do you know the cost?
[19:36:57] <alex_joni> about 1300$ I think
[19:37:00] <alex_joni> or a bit more
[19:37:11] <SWPadnos> sure - I'm just looking for the other things that people need to actually make parts
[19:37:35] <SWPadnos> I thikn that's one of the major reasons people use Mach and DeskCNC - all their other tools run on Windows
[19:45:30] <rayh> Part of the problem will always be the software of choice.
[19:45:52] <rayh> If they are a mastercam user you won't get them to change no matter how hard you try.'
[19:46:14] <rayh> And there are no mastercam workalikes for Linux.
[19:46:25] <rayh> vmware can handle some of the problems
[19:46:39] <alex_joni> so does wine
[19:46:39] <rayh> But none of that is a "cheap" solution.
[19:46:42] <alex_joni> but with hassle
[19:47:12] <rayh> Did we get anywhere with naming conventions for HAL?
[19:48:13] <alex_joni> not much
[19:48:18] <alex_joni> jmk did some cleaning up
[19:48:36] <alex_joni> but rather for '-' vs '_'
[19:48:36] <alex_joni> not naming
[19:51:28] <SWPadnos> thatnks for the view on CAM (was getting rid of mormons)
[19:51:28] <rayh> I am needing to make a disk and ship with some hardware. Was hoping that the pin naming would stay constant for a while.
[19:52:02] <alex_joni> I think it'll not change much
[19:52:05] <alex_joni> I hope
[19:52:12] <alex_joni> but that can be said for the release
[19:52:15] <alex_joni> not till then..
[19:52:30] <alex_joni> I plan to move configs around this weekend
[19:52:35] <SWPadnos> well - I was thinking about that, and I have a radical change to propose
[19:52:35] <rayh> Right. That is what is worrying me just a bit.
[19:52:48] <rayh> ah good. What are you thinking for it.
[19:52:57] <alex_joni> what we have discussed
[19:53:04] <SWPadnos> well - (regarding HAL naming)
[19:53:05] <alex_joni> configs/stg/*
[19:53:12] <alex_joni> configs/motenc/*
[19:53:13] <SWPadnos> oh - him, not me ;)
[19:53:18] <alex_joni> configs/steppers/*
[19:53:21] <rayh> both of you
[19:53:24] <alex_joni> configs/servo/*
[19:53:25] <alex_joni> etc.
[19:53:28] <SWPadnos> heh - I'll wait
[19:53:43] <alex_joni> and some basic files in configs/
[19:53:50] <rayh> k
[19:53:53] <alex_joni> like core_servo.hal, core_stepper.hal, emc.nml
[19:53:58] <SWPadnos> the real question is the search order, I think (if there is one)
[19:54:07] <alex_joni> always current dir
[19:54:17] <alex_joni> if not found try once in configs/
[19:54:19] <rayh> when we have an operational make install, where are the hunks of emc2 likely to reside?
[19:54:20] <alex_joni> then bail out
[19:54:20] <SWPadnos> ok, and you specify ../ for the core_* files
[19:54:53] <alex_joni> rayh: check the directory.map
[19:55:01] <alex_joni> emc2/directory.map
[19:55:08] <alex_joni> bottom part describes installed system
[19:56:37] <SWPadnos> nothing in the user directories? (such as part files)?
[19:56:41] <rayh> what no /usr/sbin/emc?
[19:57:46] <alex_joni> sbin?
[19:58:23] <alex_joni> I think emc should be in /usr/local/bin
[19:58:26] <alex_joni> and have sudo inside
[19:58:33] <alex_joni> just like paul did it in bdi4
[20:00:01] <rayh> If there were an emc executable, I'd like to see a first arg that pointed to the name of the set of configs
[20:00:12] <rayh> emc m5i20
[20:00:23] <rayh> would be my ideal startup command.
[20:00:50] <rayh> emc upc
[20:00:54] <rayh> emc usc
[20:01:50] <alex_joni> right.. that can be done by the startup script
[20:02:14] <rayh> does the startup script replace emc.run?
[20:02:45] <cradek> I agree emc, not emc.run, should be the command installed in the PATH
[20:03:11] <alex_joni> the startup script is actually install.run ;)
[20:03:19] <alex_joni> probably not a good name
[20:03:33] <alex_joni> but that gets copied to PATH as emc.run now, could be emc
[20:04:05] <SWPadnos> yes - drop the .run, please ;)
[20:04:13] <alex_joni> * alex_joni will do that
[20:04:24] <alex_joni> I'm tempted to drop emc.run aswell
[20:04:39] <alex_joni> and keep only the current install.run.in named emc.in
[20:04:55] <alex_joni> then configure will rename it to emc (and replace some stuff in it)
[20:05:04] <cradek> sure, I think you should do that
[20:05:21] <alex_joni> I was only reluctant to do that because of the cvs history of the file..
[20:05:31] <SWPadnos> will that affect the way you run from a non-install tree?
[20:05:36] <cradek> make a new file
[20:05:43] <rayh> so the "generic" stepper and servo will just be emc step
[20:05:48] <cradek> zero out the old file and check it in with a comment that it has been renamed to [new name]
[20:05:52] <rayh> and emc servo
[20:06:10] <cradek> I think that's the only way to "rename"
[20:06:21] <SWPadnos> or change to svn ;)
[20:06:44] <rayh> what is svn?
[20:06:49] <SWPadnos> subversion
[20:07:07] <SWPadnos> another versioning system, based on CVS
[20:07:13] <alex_joni> SF doesn't do svn, so not possible
[20:07:32] <SWPadnos> but with some extensions, such as renaming files and directories, while preserving history
[20:07:46] <SWPadnos> right - not that it would be a good thing just for renaming anyway
[20:09:00] <rayh> I'm going to start work on HAL_Tree. brb
[20:13:28] <SWPadnos> so - wanna hear my radical idea on HAL pin naming?
[20:14:03] <rayh> Yes...I do!
[20:14:28] <SWPadnos> OK - get rid of all the ppmc.* or stg.* parts of inputs and outputs
[20:14:55] <SWPadnos> you load a driver, and it exports N DIN pins, M DOUT pins, and X or Y analog inputs and outputs
[20:15:14] <alex_joni> SWPadnos: care to reply that to my email?
[20:15:22] <alex_joni> I sent one ages ago about this :D
[20:15:32] <SWPadnos> I was thinking about this in terms of abstraction (the A in HAL)
[20:15:45] <alex_joni> but then you might get troubles..
[20:15:47] <SWPadnos> ok - I know it's come up before - I think jmk vetoed it at Fest ;)
[20:15:51] <alex_joni> if you have 2 stg's
[20:15:59] <alex_joni> or 2 similar boards, exporting 5 dacs
[20:16:11] <alex_joni> you won't know who's dac it is
[20:16:15] <alex_joni> or get naming conflicts
[20:16:20] <SWPadnos> no problem - the first outputs dout 0-7, and the second is dout 8-15
[20:16:39] <SWPadnos> no - there's a known search order
[20:16:54] <SWPadnos> that could change with PCI slots (on jumperless cards)
[20:17:06] <alex_joni> that will be confusing
[20:17:12] <SWPadnos> when you load parport, you specify the port order (or use the default order)
[20:17:18] <SWPadnos> same with ppmc
[20:17:18] <alex_joni> remembering that dout 5-17 belongs to parport
[20:17:25] <alex_joni> and 18-20 to the first stg
[20:17:30] <alex_joni> and 30-45 to iocontrol
[20:17:32] <alex_joni> :(
[20:17:34] <alex_joni> yuck
[20:17:44] <SWPadnos> parport is a weird one because it uses the pin numbers, rather than sequential numbering
[20:18:02] <SWPadnos> well - it makes perfect sense though
[20:18:27] <SWPadnos> let's look at a measure of abstraction: how much needs to change at a high level, if something at the lower level changes?
[20:18:28] <alex_joni> I wouldn't wanna remember that
[20:18:38] <alex_joni> let me point one more thing out
[20:18:43] <SWPadnos> ok
[20:18:44] <alex_joni> what if I remove a card one day..
[20:18:54] <alex_joni> all the hal files will be scrap
[20:18:58] <SWPadnos> true
[20:18:59] <alex_joni> because of the numbering
[20:19:00] <alex_joni> :(
[20:19:11] <SWPadnos> what if you put in a STG card instead of a ppmc card?
[20:19:26] <SWPadnos> all your hal files are crap, even if they export the exact same I/Os
[20:19:28] <rayh> No if you remove hardware, it will be crap no matter how you name em.
[20:19:38] <SWPadnos> because some are called ppmc.*, and others are stg.*
[20:20:41] <SWPadnos> basically, the HAL allows you to reconfigure things nicely, but you still have to specify the exact device and port number of every connection
[20:21:16] <SWPadnos> equivalent hardware isn't equivalent due to naming conventions (ie, an 8255 card, vs. a couple of parports)
[20:21:48] <alex_joni> I don't agree..
[20:21:55] <alex_joni> an io pin should be named the same
[20:22:04] <alex_joni> but with the board specifier infront of it
[20:22:26] <SWPadnos> sure, but one will be "8255card.dout.00", and the other will be parport.0.pin_17
[20:22:48] <SWPadnos> well - I said it was radical ;)
[20:23:41] <SWPadnos> I'd like to have a .hal file that says "connect motion.enable to digital output 1", and have that usaable on parport, 8255, ppmc, stg, m5i20, etc. systems
[20:23:52] <rayh> It would be nice to be able to substitute devices more easily that we do now.
[20:24:17] <rayh> for example ppmc.pwm vs ppmc.stepgen.
[20:24:47] <SWPadnos> yeah - they should be ppmc.aoutN - they're just a different form of analog output
[20:24:50] <rayh> most of the pins do the same things
[20:25:07] <rayh> even step and direction vs pwm and direction/
[20:25:29] <rayh> a few params are different.
[20:25:33] <SWPadnos> the trouble (other than alex's poit, which is valid) is that you don't want the files to be syntactically correct, but not work due to changes in how things are interpreted
[20:25:36] <SWPadnos> point
[20:26:05] <SWPadnos> e.g., the scale for pwm is different from the scale for stepgen
[20:26:27] <rayh> True but only for convenience.
[20:27:08] <SWPadnos> they could be made the same - they should both have a max, min, scale, and offset param
[20:27:34] <SWPadnos> but then you still need an extra param for the pwm - frequency
[20:27:50] <SWPadnos> and for the stepgen - pulse width
[20:28:30] <SWPadnos> so there would be issues, but at least you wouldn't have to search / replace all ppmc.*.stepgen with ppmc.*.pwm ...
[20:29:42] <rayh> IMO the separation of configs/upc/ v configs/usc/ will help quite a bit.
[20:29:52] <SWPadnos> yes
[20:32:09] <rayh> I don't want to wait for HAL refactor.
[20:32:17] <SWPadnos> anyway - even if we don't get rid of the board names, there are other things to consider
[20:32:46] <SWPadnos> first, get rid of the blah.blah.in-xx-not pin
[20:33:01] <SWPadnos> we discussed this a little before
[20:33:41] <SWPadnos> ppmc.0.dout.00-output becomes ppmc.0.dout-00 (much like the format in your mail)
[20:34:19] <SWPadnos> or was that dout.00-input? (sonce it's an input in the driver ...)
[20:35:18] <alex_joni> din is input
[20:35:40] <rayh> dinn is in not?
[20:35:43] <alex_joni> dout is output
[20:35:51] <alex_joni> dout.00-input is bogus ;)
[20:36:19] <SWP_Away> yes it is ;)
[20:36:50] <SWP_Away> ok - I have ppmc.0.dout.00.out
[20:36:57] <SWP_Away> the extra .out seems redundant
[20:37:33] <SWP_Away> for the inputs, get rid of the -not pins, and add a param to invert them if necessary
[20:37:44] <SWP_Away> (this mirrors the output pins)
[20:38:29] <rayh> an in can have only one link?
[20:38:30] <alex_joni> it's easier to have the -not
[20:38:38] <alex_joni> than an extra param
[20:38:45] <SWP_Away> or an extra pin
[20:39:11] <SWP_Away> the external input will likely be either active high or active low - not both
[20:39:22] <alex_joni> extra -not pin is easier to connect to than another setp for invert
[20:39:58] <SWP_Away> jmk's concern was that you may need both for some reason, though you could just use an invert block for those rare cases
[20:56:55] <alex_joni> anyways.. can't write to both.. that's bad
[20:57:24] <SWP_Away> that's why output pins have an invert param
[21:01:38] <rayh> just helped a guy in detroit start up a m5i20 card.
[21:01:44] <SWP_Away> cool
[21:01:53] <SWP_Away> I should install that in some machine here
[21:01:58] <rayh> He's connecting motors now and will call back with a report in 30 minutes.
[21:04:03] <SWP_Away> is there anything else you'd like to see in the script mode of halcmd?
[21:04:27] <rayh> Let me take a few minutes and work up the first set of nodes.
[21:04:32] <SWP_Away> ok
[21:04:36] <alex_joni> great
[21:04:49] <rayh> I'll base these on the "name" returned by -s
[21:05:19] <SWP_Away> ok - that should work
[21:05:47] <SWP_Away> you should almost be able to take one of the sample programs that does directory trees, and change the delimiter from '/' to '.'
[21:06:59] <rayh> damn lost the work I did to an update.
[21:07:15] <SWP_Away> bummer
[21:11:39] <SWP_Away> ok - so I'm cleaning up the default ini file ...
[21:12:10] <SWP_Away> it seems that all of the XXX_INDEX are now useless, as are the XXX_POLARITY
[21:12:17] <rayh> my initial thought is to make the top node pin or param or sig
[21:12:52] <rayh> They are stillused by IO_Show.tcl
[21:13:11] <rayh> should rip that out of it or it out of emc2
[21:13:31] <SWP_Away> yep - I noticed that they were used there
[21:13:44] <SWP_Away> hal_show should probably look for certain signal names
[21:26:28] <dmwaters> {global notice} Hi all, that split was my fault. had to update the server's firewall, and it apparrently reset the connections on the server. I apologize for this, and thank you for using freenode!
[21:30:04] <rayh> SWPadnos: are you seeing an easier way to setup nodes than reading each line of reply and searching for unique words.
[21:31:11] <alex_joni> You cannot GHOST yourself.
[21:31:14] <alex_joni> lol
[21:36:27] <alex_joni> night all..
[21:43:20] <cradek_> cradek_ is now known as cradek
[22:13:55] <SWPadnos> phone
[22:17:54] <SWPadnos_> rayh: still there?
[22:18:05] <rayh> Yep
[22:18:19] <SWPadnos_> ok - what ws the question again? :)
[22:18:33] <SWPadnos_> (it seems I missed some stuff on this machie)
[22:18:45] <rayh> My approach is to issue a show -s pin
[22:19:28] <rayh> condense the list to a unique set of the first word of each returned line.
[22:19:39] <SWPadnos_> yep - group by owner name (first field), then you can parse the pin name, splitting the tree at every '.'
[22:19:46] <rayh> and those are the nodes under pin
[22:20:06] <rayh> right.
[22:20:10] <SWPadnos_> ok - and do the same thing for param
[22:20:22] <SWPadnos_> signals are differnt, because they have no owner
[22:20:22] <rayh> yes and signal as well
[22:20:34] <rayh> right just the name of the signal
[22:20:50] <SWPadnos_> and in fact, they may have no connected pins either
[22:21:16] <rayh> I suppose that's true.
[22:21:19] <SWPadnos_> ok - so you list all the sigs, then the branches are the connected pins
[22:21:43] <SWPadnos_> one thing I had considered was to send the output signal first, followed by any input signals
[22:22:16] <SWPadnos_> there would just have to be a "nothing" namd, like '-', if there is no input (or output) pin connected
[22:22:23] <SWPadnos_> s/namd/name/
[22:23:20] <rayh> One feature we will want is the state of a pin, param, or signal
[22:24:03] <rayh> We can get this from show or show -s
[22:24:07] <SWPadnos_> yes
[22:24:30] <SWPadnos_> I can change the signal thing now, here's what would happen:
[22:24:38] <rayh> but if there were a way to issue a pin name and have it return
[22:24:58] <SWPadnos_> how do you mean?
[22:25:34] <rayh> I'm thinking of a list of pins or params or signals that I want to watch for state changes
[22:25:45] <SWPadnos_> yes - that won't happen soon
[22:26:11] <SWPadnos_> it would require changes to the command line tokenizer, among other things
[22:26:31] <rayh> You did have some awk things that would do that. That should be sufficient.
[22:26:57] <SWPadnos_> they only work if you can construct a regular expression out of the list
[22:27:08] <SWPadnos_> (which I suppose is always possible, with {xxx,yyy}
[22:27:48] <SWPadnos_> but you have to be more careful with regexps - the snippet ppmc.0 will match ppmc[any single character]0
[22:28:27] <SWPadnos_> I found that out when all floats were being returned, when I was looking for '.00.' :)
[22:28:59] <rayh> Okay. That should be interesting.
[22:29:16] <SWPadnos_> there is probably a way to construct a regexp that will look at only a certain word, but I don't know how to do that
[22:29:18] <rayh> How does halmeter do it's values?
[22:29:37] <SWPadnos_> it's only looking at one pin, so it just uses the full name, I'd bet
[22:29:46] <alex_joni> halmeter actually connects to hal_lib
[22:30:02] <alex_joni> and travels the SHM for pins and such
[22:30:07] <SWPadnos_> ok - that's the easy way ;)
[22:30:15] <rayh> ah. That explains it
[22:30:17] <alex_joni> it's a .c file afterall
[22:31:29] <SWPadnos_> rayh: tcl has some regexp capabilities - you should be able to use those after reading in all the information
[22:36:35] <rayh> right. I should but...
[22:37:04] <rayh> let me try and see if I can get far enough with nodes to need the next step.
[22:37:27] <SWPadnos_> actually - if you use awk to print the pin name then the value, you should be able to load those into a tcl array
[22:37:35] <SWPadnos_> then look up the values by pin name in tcl
[22:39:15] <rayh> Yes. I should.
[22:39:32] <rayh> SO is home. Be back later.
[22:39:39] <rayh> Thanks guys
[22:39:47] <SWPadnos_> see a
[22:39:49] <SWPadnos_> ya
[23:32:01] <SWPadnos_> SWPadnos_ is now known as SWP_Away