#emc-devel | Logs for 2007-09-12

[01:07:54] <SWPadnos> the only thing I saw that's different in pyvcp.py is the check for name == __main__ (other than some deleted comments)
[01:08:08] <SWPadnos> between what's in 2.1.7 vs TRUNK
[01:08:16] <jepler> the main changes are in lib/python
[01:08:24] <SWPadnos> ok
[01:08:31] <jepler> vcpparse.py and pyvcp_widgets.py or something like that
[01:08:57] <SWPadnos> right - I saw that those were imported but didn't chase it that far
[01:46:00] <jepler> SWPadnos: by the way, with a small change to AXIS (checked in on TRUNK) it's possible to use [AXIS_n]SCALE instead of INPUT_SCALE with only a halfile change
[01:46:04] <jepler> stepconf will use [AXIS_n]SCALE
[01:46:26] <SWPadnos> I saw that - cool
[01:47:34] <SWPadnos> though keystick (or xemc) still uses INPUT_SCALE
[01:47:36] <SWPadnos> fwiw
[12:15:24] <cradek_> cradek_ is now known as cradek
[14:30:27] <SWPadnos> hmm
[14:30:56] <SWPadnos> so pete sent me this hostmot2 source and bitfile for the 5i22
[14:31:41] <SWPadnos> it's got 4 SPI, 4 UART, 12 PWMgen, 12 stepgen, and 6 quadrature counters
[14:32:20] <SWPadnos> any I/O bits can be set for the alternate function or simple I/O
[14:32:56] <SWPadnos> (I think it may even be possible to use e.g. the UART RX bit as an I/O if you only need to transmit serial data)
[14:33:15] <jepler> sounds interesting
[14:33:31] <SWPadnos> yeah, it does
[14:34:01] <cradek> what exactly is meant by uart?
[14:34:04] <SWPadnos> serial port
[14:34:39] <SWPadnos> (universal asynchronous receiver transmitter)
[14:34:56] <cradek> I know what a uart is, I don't see how it would be used in the mesa
[14:35:01] <SWPadnos> heh
[14:35:12] <SWPadnos> modbus?
[14:35:25] <SWPadnos> otehr microcontroller-based outboard - err - boards
[14:35:42] <cradek> ok I can see that
[14:35:57] <cradek> like an avr in a front panel thing that also uses ttl-ish serial
[14:36:11] <SWPadnos> I don't know about buffering, but aside from that, you can write a single 32-bit word and set the UART to transmit 1, 2, 3, or 4 bytes in sequence
[14:36:12] <jepler> what's hard (for me) to see is how to fit serial into the HAL model
[14:36:13] <SWPadnos> yep
[14:36:19] <SWPadnos> yeah, that is a hard one
[14:36:20] <cradek> yep
[14:36:43] <cradek> you could have DPP (breakout to bits or something) in the hal driver itself
[14:36:54] <SWPadnos> with a few data converters, it should be possible to make HALs that can deal with simple serial devices
[14:37:52] <SWPadnos> I guess the serial ports could export u32 pins, and the "device driver" would take an s32 in and have whatever outputs the data means
[14:38:00] <SWPadnos> s/means/represents/
[14:38:34] <jepler> if at most one unit is transferred per period, you can have 1 IO Bit (writer sets to 1 when data available, reader sets to 0 when data consumed) plus one other HAL pin to carry the actual data
[14:38:38] <SWPadnos> there would need to be some other handshaking as well
[14:38:55] <SWPadnos> you can have 1 I/O "word"
[14:39:01] <SWPadnos> which in this case is 32 bits
[14:39:15] <SWPadnos> for a 16550 it would more likely be 8 bits
[14:39:27] <SWPadnos> nevermind - I get what you're saying now
[14:41:15] <jepler> make the bus always u32 (there's not an 8-bit HAL type anyway) and the producer and consumer have to agree on how many of those bits are meaningful?
[14:41:39] <SWPadnos> I think there are several places where a "block" type would be handy - this is one of them
[14:41:41] <SWPadnos> yes
[14:42:18] <SWPadnos> a ring buffer would be a handy HAL connection
[14:42:19] <jepler> well .. rtapi provides FIFOs. HAL just needs to provide a fifo type as well
[14:42:24] <SWPadnos> yeah
[14:42:35] <jepler> * jepler waves his hands about the details
[14:42:41] <SWPadnos> * SWPadnos waves back
[14:42:47] <jepler> if you want it, you'll figure it out
[14:43:02] <SWPadnos> yep. I just don't know if I can find a jmk-compatible solution :)
[14:43:55] <SWPadnos> we had discussed some methods of transferring larger data types a couple of years ago. it's pretty easy if there's at most one writer, and that's in the faster thread (I think)
[14:50:44] <jepler> larger data types like doubles and long longs? It seems like the considerations for a word-oriented ring buffer are probably simpler than that ..
[14:50:58] <jepler> (for the one producer / one consumer case at any rate)
[14:51:13] <SWPadnos> either one needs to update multiple values in an apparently atomic way
[14:51:35] <SWPadnos> but yes, we were discussing long long and double
[14:52:14] <SWPadnos> I think a two-value buffer plus an atomically-updated pointer (or selector) was the basic concept
[14:52:21] <SWPadnos> er - two-element
[14:52:46] <SWPadnos> but multiple readers become a problem
[14:54:09] <jepler> for a ring buffer you only need the property that the consumer see the write to update the buffer end *after* the writes to add data to the buffer. I think.
[14:54:24] <SWPadnos> I believe that's true
[14:54:52] <SWPadnos> and the consumer needs to read a data value before updating the tail pointer
[14:55:07] <SWPadnos> or head pointer - you know, whichever it is :)
[16:06:30] <cradek> * cradek just grudgingly answered another question with "fixed in 2.2"
[16:06:50] <cradek> it's almost as if we ought to release that
[16:07:55] <SWPadnos> oh yeah - as if
[16:08:41] <SWPadnos> oh - I guess we're sort of waiting for the 5i2x stuff?
[16:09:01] <SWPadnos> was that pseudo-promised for 2.2?
[16:09:27] <cradek> I don't think we've talked about it enough for me to be confident I know exactly what is causing the wait
[16:09:46] <cradek> hm, that was roundabout
[16:09:52] <cradek> but accurate I think
[16:10:53] <SWPadnos> I agree
[16:12:09] <SWPadnos> now this is funny. I just got an ad to attend a coil-winding expo in Chicago
[16:12:21] <cradek> sounds exciting
[16:12:35] <SWPadnos> um - yeah: http://www.coilwindingexpo.com/
[16:12:47] <SWPadnos> it would be neat - I have no idea how a toroid winder works, for instance
[16:13:01] <cradek> CWIEME? that's unfortunately pronouncable
[16:13:14] <SWPadnos> elmer fudd asking for coffee seasoning ;)
[16:13:21] <cradek> yeah it would be neat to see the machinery
[16:14:36] <cradek> how does everyone feel about an extension to gcode that loads a tool table entry?
[16:15:03] <cradek> as a nice side effect, that would give us a way for the gui to do it too
[16:15:22] <SWPadnos> I don't think I'd want an extension that could change the persistent table, but something that can say "use these numbers for now" is fine (and already there, I think)
[16:15:28] <cradek> on the bridgeport you can program T01/1.0/0.5 to set tool one to 1" long .5" dia
[16:15:53] <SWPadnos> unless there were some provisions for write permissions
[16:16:04] <cradek> what do you mean write permissions?
[16:16:23] <SWPadnos> ie, not every user of the machine should be allowed to change the persistent table
[16:16:55] <cradek> I don't think that's an important consideration, and if it is, it should be solved by unix, not emc
[16:17:40] <SWPadnos> ok, that's a fair statement
[16:18:01] <cradek> emc's job might be to gracefully handle an unwritable tool table
[16:18:06] <SWPadnos> does emc run as the user who started it?
[16:18:10] <SWPadnos> right
[16:18:10] <cradek> but it stops there
[16:18:16] <cradek> yes of course
[16:18:48] <SWPadnos> ok - it seems that any operator needs write access to some files (.var for example)
[16:18:57] <cradek> yes
[16:19:05] <jepler> cradek: the problem with your theory is that the interpreter doesn't currently store the tool table; it requests tool table entries with the canon call GET_EXTERNAL_TOOL_TABLE.
[16:19:21] <jepler> er, one problem with your proposal is ..
[16:19:31] <SWPadnos> so all we need to do is add SET_EXTERNAL_TOOL_TABLE ;)
[16:19:33] <cradek> jepler: there is/was nml to write an entry.
[16:19:53] <cradek> it would need to be revived if it's bitrotted
[16:19:58] <SWPadnos> sorry - I should have quoted "all"
[16:20:48] <cradek> I'm not saying it's trivial to implement. I want to know what people think about the functionality I'm proposing
[16:21:37] <jepler> if the goal is to let GUIs change the tool table, forcing them to go through gcode seems to be an extra complication
[16:21:49] <cradek> I agree, but that's not the only goal
[16:22:06] <cradek> the main goal is a "set of tools" can go with a program in a natural way
[16:22:30] <SWPadnos> but the physical tools also have to match, and you can't email those
[16:22:53] <cradek> it's not about email really
[16:23:17] <jepler> and one use of the tool table is to specify actual cutter diameter when the gcode is written for nominal cutter diameter with radius comp
[16:23:19] <cradek> maybe it's a bad idea, grounded in a limited-size tool table
[16:23:46] <SWPadnos> limited by EMC or by physical machines?
[16:23:59] <cradek> yes radius comp can be used in different ways, and depending on what the gcode is doing, you want a different tool table
[16:24:54] <cradek> SWPadnos: on the bridgeport it's a limited size and maybe that's why you might want to configure a "set of tools" in the gcode
[16:25:27] <cradek> some people have proposed G10 L1 P1 (I think) as a way to write to T01
[16:25:54] <cradek> (which seems clumsier to me)
[16:26:39] <jepler> G10 has the advantage that it's exclusive of G1 so you're free to use X, Y and Z without it meaning "move somewhere"...
[16:26:41] <SWPadnos> is the actual command exactly as you wrote above? "T01/1.0/0.5"
[16:26:58] <cradek> SWPadnos: yes (seems a bit bizarre)
[16:27:03] <jepler> you don't type "/" do you?
[16:27:04] <SWPadnos> or R for that matter
[16:27:09] <cradek> yes
[16:27:12] <jepler> oh.
[16:27:22] <SWPadnos> does that command also prep tool 1?
[16:27:22] <cradek> I'm not proposing any particular syntax either
[16:27:34] <cradek> SWPadnos: I think so but I'm not entirely sure
[16:27:48] <SWPadnos> ok. I'm concerned about a semantic change to Txx
[16:27:50] <cradek> it's a manual tool change machine, so there's not much prep to do
[16:27:52] <SWPadnos> heh
[16:28:01] <cradek> ... except display T01 on the screen
[16:28:27] <cradek> but ... I'm not proposing any particular syntax
[16:28:32] <SWPadnos> sure
[16:29:42] <cradek> I can imagine handing my operator (haha) a gcode program and a set of tools I've put in holders and measured, and the holders have stickers saying T1,T2,T3 on them
[16:30:23] <jepler> handing (haha)
[16:30:50] <SWPadnos> ok. I can see that as being useful
[16:31:02] <SWPadnos> you could also hand the operator a tool file though
[16:31:08] <cradek> yes
[16:31:17] <cradek> the BP can also load a tool file from tape
[16:31:24] <cradek> (it may have that same format, I haven't looked)
[16:31:46] <cradek> maybe this is nothing.
[16:31:46] <jepler> bbl
[16:31:51] <SWPadnos> so another approach (just ideas here, not saying which might be better) would be to gracefully support loading of other tool tables
[16:31:57] <cradek> of course we need good gui support for tool table editing
[16:32:08] <cradek> SWPadnos: also true
[16:32:25] <cradek> bbl, lunchtime
[16:32:26] <SWPadnos> see you
[18:15:14] <cradek> I see EMC_TOOL_SET_OFFSET is still all over the place
[18:15:29] <cradek> I don't know whether anything generates that call
[18:15:54] <cradek> but it eventually does call saveToolTable(), which then errors
[18:16:12] <cradek> fprintf(stderr,"I thought saveToolTable wasn't used. Please report.\n"); return 0;
[18:19:29] <cradek> if we revive it, it needs to know about lathe tool tables
[18:20:59] <cradek> even xemc does not call that
[18:21:31] <cradek> but it has a window that shows the tool file, and has two buttons: "Save and Load Them", "Don't Save and Load Them"
[18:22:07] <cradek> ... which is so funny in that way that all Athena programs are
[18:27:40] <alex_joni> athena?
[18:30:00] <cradek> in keystick you can load a specified tool table
[18:31:11] <alex_joni> oh, really?
[18:31:35] <cradek> well I don't know if it works, but it's in the gui
[18:31:48] <cradek> I haven't found if there is a way to set an entry in it though
[18:31:50] <alex_joni> I must have at some point
[18:36:37] <cradek> jepler: keystick and axis have SN problems too. keystick smartly reports "timeout sending command"
[18:39:09] <cradek> Traj scale: 1.000, X Scale: 0.000, Y Scale: 0.000 ...
[18:39:44] <cradek> interesting stuff in keystick and xemc
[18:46:00] <alex_joni> 0?
[18:46:51] <cradek> yeah but they don't do anything I'm sure
[20:47:26] <jims65311> Anyone available to give a noob a few pointers toward possibly making a (hopefully) trivial mod to the Axis interface?
[20:48:41] <cradek> best to just ask your question and see if someone can help
[20:53:41] <jims65311> I'd like to add new key bindings for the Jog Speed slider - right now, it uses the '.' and ',' keys to decrease/increase the slider position, but I tend to use 3-4 specific speeds for jogging, edge finding, etc, so I'd like to setup some 'presets' that would allow me to jump to one of a small set of values. The Feed Override slider acts in a similar way right now - you hit keys 1-0 (and `), and it goes to 0-100% in 10% increments. I see there is an
[20:54:11] <cradek> darn, your message was cut off at "I see there is an"
[20:54:28] <jims65311> heh, I'll try sending it in 2 chunks
[20:54:40] <jims65311> I'd like to add new key bindings for the Jog Speed slider - right now, it uses the '.' and ',' keys to decrease/increase the slider position, but I tend to use 3-4 specific speeds for jogging, edge finding, etc, so I'd like to setup some 'presets' that would allow me to jump to one of a small set of values. The Feed Override slider acts in a similar way right now - you hit keys 1-0 (and `), and it goes to 0-100% in 10% increments. I see there is an
[20:54:50] <jims65311> The .tcl file seems to sort of hard-bind keys to widgets, while the .py file seems to bind keys to logic. I'm new to Python and TCL, and while I don't mind some RTFM, I'd rather spend more time using Axis and less time modifying it, so if someone can give me some hints/help getting started, I'd be much obliged.
[20:55:20] <jepler> you can add some customizations to ~/.axisrc though I don't guarantee that any particular customization will work from release to release .. http://linuxcnc.org/docs/html/gui/axis/#SECTION001114000000000000000
[20:56:41] <cradek> seems like you can call vars.jog_speed.set(...) from your key binding
[20:56:55] <cradek> maybe the biggest problem will be coming up with some free keys that make sense
[20:57:15] <jims65311> agreed - I was going to hijack the 1-5 keys or such, as I don't find myself using feed override at all
[20:57:33] <jims65311> (maybe 6-10 since 1-5 have a dual use, it looks like)
[20:57:36] <jepler> let me see if I can find the incantation that works
[20:58:11] <cradek> I guess we all need sun keyboards with the dual sets of function keys
[20:58:53] <jims65311> my ultimate goal is to specify a set number of preset values via the ini file and read those in to react to the key bindings, but I need to slither on my belly before I can run...
[20:59:07] <jepler> root_window.bind("<exclam>", "set jog_speed .5")
[20:59:06] <jepler> root_window.bind("<at>", "set jog_speed 2")
[20:59:26] <jims65311> ok, now for the 'this guy is a total friggin idiot' phase...
[20:59:34] <jims65311> is that in the .py or the .tcl file?
[20:59:40] <jepler> this makes shift-1 ("!" on my US keyboard) set the jog speed to .5 and shift-2 ("@" n my US keyboard) set the jog speed to 2
[20:59:46] <jepler> this is for your ~/.axisrc file
[20:59:51] <jims65311> and can someone briefly explain the interaction between the two?
[20:59:55] <jims65311> oh, I see
[21:00:20] <jims65311> well geez, that'd be pretty straightforward
[21:00:24] <jims65311> I can put the jackhammer away...
[21:00:26] <jepler> the relationship between the .py and the .tcl is 'pretty complicated'
[21:00:50] <jepler> if you want the "1" key, then you would use root_window.bind("1", "set jog_speed ...")
[21:01:01] <jepler> I tested this with the development version, I'm not 100% sure it works with the 2.1.7 version.
[21:01:07] <jepler> but I think the odds are good
[21:01:42] <jims65311> what would be the result of that given that the 1 key is currently overloaded for 2 different operations?
[21:01:52] <jepler> this will replace the earlier definition
[21:01:59] <jims65311> ok
[21:03:05] <jims65311> well, that's a fantastic start - your sample code combined w/ the ~/.axisrc will go a long way toward helping out!
[21:03:07] <jims65311> THANK YOU!!
[21:03:17] <jepler> does it work?
[21:03:29] <jims65311> (I'd love to hear the short version of the 'pretty complicated' explanation if anyone is game)
[21:03:49] <jims65311> I'm on a Windows box right now - will have to try it out at home on my Ubuntu setup this evening
[21:04:02] <jepler> OK, come back and let us know, particularly if it doesn't work..
[21:04:35] <jepler> axis is a Python application which uses Tkinter for the GUI -- Tkinter is based on Tk, which is just one of the many GUI libraries that people use on Linux
[21:04:38] <jims65311> Will Do! Thanks Much for taking the time. Never used IRC before. Instant Gratification is a great thing! :-)
[21:04:59] <jepler> Tk was first made to go with this language called Tcl
[21:05:50] <jepler> I work a lot with the Tcl/Tk combination in my day job, so sometimes it feels "more natural" to write a particular piece of behavior in Tcl instead of in Python
[21:06:34] <jepler> unfortunately, when I look back there is often little reason that this or that thing was written in Tcl instead of in Python
[21:06:47] <jepler> not many people who write Python applications would have written it this way
[21:08:01] <jims65311> so this .axisrc file - is this Python or Tcl/Tk?
[21:08:08] <jepler> it's Python
[21:08:52] <jims65311> (and FWIW, not many people who write Python or much of anything else would have taken the time it clearly took to write Axis! :-)
[21:09:02] <jims65311> I'm just a home hobby guy, but I love it
[21:09:12] <jepler> that's always nice to hear
[21:09:16] <jepler> I'm just a hobby guy too
[21:09:36] <jepler> unfortunately nobody's yet sent me a suitcase full of money for my efforts
[21:09:48] <jims65311> heh, I used to have a small open source projet myself
[21:09:49] <cradek> funny how that never seems to happen to any of us
[21:10:03] <jims65311> I got paid in amazon.com gift certificates and once received a case of cookies... :-)
[21:10:22] <jepler> I've managed to get a few free meals but that's about it
[21:10:22] <cradek> that's cool that someone would go to the trouble
[21:10:50] <cradek> nice words are free but almost as nice to get
[21:10:57] <jims65311> :-) I hear you
[21:10:58] <cradek> glad to hear you're happy with emc/axis
[21:11:32] <jims65311> very much so - started out using Mach, and was having issues, and additionally to setup a dedicated box was going to have to buy Windows, of course
[21:11:49] <jims65311> Dl'd the Ubuntu/EMC setup and its been going strong & steady ever since
[21:11:56] <jepler> cool
[21:11:56] <jepler> bbl
[21:12:08] <cradek> hey it's time to go home
[21:12:18] <cradek> talk to you later jims65311
[21:12:20] <jims65311> yep, thanks again guys - really appreciate the help!!
[21:35:02] <SWPadnos> wow.
[21:35:22] <alex_joni> ?
[21:35:53] <SWPadnos> this hostmot2 config (4 uart, 4 SPI, 6 quadrature counters, 12 stepgen, 12 PWMgen, all I/O bits usable as generit I/O or special functions) takes only ~10% of a 5i22-1.5
[21:36:01] <SWPadnos> generic
[21:36:03] <alex_joni> heh
[21:36:15] <alex_joni> hostmot2? any reason for the name?
[21:36:25] <SWPadnos> err - because it's for the 5i22?
[21:36:39] <SWPadnos> that's what peteW called it when he sent it to me :)
[21:37:14] <SWPadnos> I'm trying to figure out if there was some error or if all that stuff is actually in there
[21:38:26] <alex_joni> I only ask because there's a hostmot8 for 8-axes
[21:38:58] <SWPadnos> ah, ok. it looks like there are only 2 of each function there
[21:39:29] <SWPadnos> phew - I was thinking that looked awfully small
[22:04:04] <cradek_> cradek_ is now known as cradek
[23:44:26] <SWPadnos> jmkasunich, do you have that VHDL book handy?