#emc-devel | Logs for 2007-08-05

[02:32:39] <cradek> bleah
[02:32:47] <jmkasunich> bleah?
[02:32:48] <cradek> I don't like G28
[02:32:52] <jmkasunich> oh
[02:33:08] <SWPLinux> heh
[02:33:11] <cradek> ngc/emc does it different from everyone else
[02:33:43] <SWPLinux> I re-read the spec, and it isn't clear about whether all or only specified axes are supposed to move
[02:33:58] <cradek> oh that's interesting, maybe I should read that
[02:34:12] <SWPLinux> but at least one axis word is required I think, which would imply that only those specified should move
[02:34:13] <cradek> I just figured emc worked according to it, but didn't look
[02:34:34] <cradek> ngc says at least one axis is required?
[02:34:57] <SWPLinux> nope - it doesn't. nevermind that
[02:35:31] <cradek> nobody (except stuart) says what coordinate system the waypoint is in
[02:35:36] <SWPLinux> at least, not in the user manual from the menu on Dapper
[02:36:19] <cradek> "All axis words are optional" (ngc)
[02:36:24] <SWPLinux> I think someone (could have been Stuart) said that it's the current system, including relative/absolute
[02:36:25] <cradek> so, it says the opposite of that
[02:36:42] <cradek> conveniently enough, that's how emc does it too
[02:36:45] <SWPLinux> right. I either read a different revision or remembered wrong
[02:36:49] <SWPLinux> I'm betting on 2
[02:37:38] <cradek> to me everyone else's definition is goofy: the axis words are overloaded, they specify which axes to move home, and also which ones have a waypoint
[02:37:46] <SWPLinux> well, one thing to think about going forward is whether the spec has the right thing to do in "modern times"
[02:38:04] <cradek> so you can't move straight up, then move them all home (like emc's G28 Z1)
[02:38:08] <SWPLinux> yeah - if you can't do G28 XYZ, then it doesn't make much sense
[02:38:28] <SWPLinux> but you could do G28 G91 X0Y0Z0 (or whichever is relative mode)
[02:38:41] <cradek> that doesn't move up first
[02:38:47] <SWPLinux> true
[02:38:53] <cradek> that's just all-home, like our current bare G28
[02:38:55] <jmkasunich> G28 G91 X0Y0Z1
[02:39:00] <SWPLinux> right
[02:39:11] <cradek> ok true
[02:39:22] <cradek> but that's not a move to Z=1, you're forced to make it relative
[02:39:33] <jmkasunich> right
[02:39:43] <jmkasunich> personally I think the intermediate move part is silly
[02:39:44] <jmkasunich> just use G0
[02:39:56] <cradek> yeah
[02:40:10] <cradek> and having to switch to relative mode to specify which axes to move is silly too
[02:40:11] <SWPLinux> heh - how about a new feature that lets each axis be specified in relative or absolute mode. just use +- for relative plus, and -+ for relative minus :)
[02:40:15] <cradek> but, that's what everyone seems to want to do
[02:40:40] <SWPLinux> or should that be -+ for plus and +- for minus?
[02:41:13] <cradek> "pull the quill up" = G91 G28 Z0 (silly?), or G0 G53 Z0 (sane?)
[02:41:35] <cradek> * cradek kicks SWPLinux
[02:41:38] <SWPLinux> heh
[02:41:57] <cradek> the "silly" way screws up a sticky mode
[02:42:02] <SWPLinux> yes
[02:42:16] <jmkasunich> its not just "pull the quill up"
[02:42:35] <SWPLinux> OT but somewhat related: are the current axis positions available as parameters?
[02:42:39] <cradek> yeah it is, that's the point of this I think
[02:42:41] <cradek> SWPLinux: no
[02:42:42] <jmkasunich> I think it was the latest email from stuart that says at least some controls DO a homing cycle
[02:42:42] <SWPLinux> ok
[02:42:48] <cradek> oh right
[02:43:07] <cradek> yeah but we're not going to do that...
[02:43:07] <SWPLinux> that's definitely counter to the EMC manual
[02:43:34] <jmkasunich> but it provides a function that can't be done any other way
[02:43:52] <jmkasunich> if G28 is just G0 G53 X0Y0Z0, why even have it?
[02:44:05] <SWPLinux> it goes to a predefined point, not 0,0,0
[02:44:09] <SWPLinux> ,0,0,0
[02:44:16] <jmkasunich> whatever
[02:45:37] <cradek> jmkasunich: < cradek> I don't like G28
[02:46:01] <steves_logging> steves_logging is now known as steve_stallings
[02:46:09] <jmkasunich> agreed
[02:47:48] <cradek> I don't see how we can avoid breaking ngc programs and still solve this
[02:48:06] <cradek> we can keep the bare-g28 behavior...
[02:48:24] <steve_stallings> I just looked up the Haas implementation. They will accept a G28 with no parameters as having no waypoint and go directly to machine X0Y0Z0, but if a parameter is present, only the axes called out will move.
[02:48:25] <cradek> but the behavior of g28z1 will be (very) different
[02:48:38] <cradek> steve_stallings: that's good to know
[02:49:19] <steve_stallings> ... and if EMC accepts a G28 this way it will not cause problems with Fanuc code since Fanuc code will never do this.
[02:49:28] <cradek> right
[02:51:09] <steve_stallings> As best I can tell the Haas does not trigger and actual homing cycle, nor do I think EMC should.
[02:51:25] <cradek> I'm glad we all agree on that...
[02:51:52] <cradek> (that would be very messy to do)
[02:51:54] <steve_stallings> For those poor soles with stepper systems that they do not trust, having a G code that would
[02:52:05] <steve_stallings> trigger a homing cycle could be useful.
[02:52:12] <cradek> SHHHH
[02:52:31] <cradek> LALALALA
[02:52:41] <jmkasunich> lol
[02:52:59] <cradek> haha "soles"
[02:53:13] <jmkasunich> ?
[02:53:51] <steve_stallings> and that was "wet" computer between my ears, not a spell checker....
[02:54:14] <cradek> oh sorry, I figured it was a pun on purpose
[02:54:31] <steve_stallings> OK, yea, thats what it was....
[02:54:36] <cradek> :-)
[02:55:52] <steve_stallings> so, what is the problem with EMC's G28 as Stuart sees it?
[02:55:56] <Skullworks-PGAB> Cradek - in G90 I believe the waypoint is in the current (active) coordinate system - but it is also an error to call G28 G90 if tool offset has not been canceled first (G49)
[02:55:58] <cradek> well I have always used bare G28/G30 and I think the change we're converting toward wouldn't change that behavior
[02:56:12] <cradek> err converging
[02:56:28] <cradek> steve_stallings: it changes the behavior of emc's e.g. G28 Z1
[02:57:08] <steve_stallings> and EMC does what? stops with Z at machine 1.0?
[02:57:28] <cradek> no, it moves Z to 1 in the active coord system, then moves all axes to 0 in world coords
[02:57:45] <cradek> stuart's way would move Z to 1 (active) then Z to 0 (world)
[02:58:15] <steve_stallings> ah, so the moves all axes is the problem, and I agree with Stuart (and Fanuc and Haas)
[02:59:32] <cradek> I sure accept that we're the rogue control here and we should get in line -- but I'm very unhappy every time we break everyone's old ngc programs
[02:59:49] <cradek> I guess that's what release notes are for
[02:59:52] <steve_stallings> understood
[03:03:48] <cradek> now that I know the behavior we want, I wonder if I can get it right
[03:09:06] <cradek> who can help me test this?
[03:13:09] <steve_stallings> where is Stuart when you need him?
[03:13:19] <jmkasunich> in Wicheta
[03:13:44] <steve_stallings> says he who doesn't even have an EMC sim machine at the moment....
[03:16:23] <Skullworks-PGAB> From the last Digest I received it appears Stuart is saying each execution of G28 is doing a homing/index seek.
[03:16:51] <cradek> at the very end, he says some controls do and some don't, and he thinks emc shouldn't
[03:17:47] <Skullworks-PGAB> I'm thinking that maybe other than at the program header he might want to use G30 in place of G28
[03:18:48] <cradek> yes g28 and g30 will definitely work the same
[03:19:37] <Skullworks-PGAB> but does G30 do a index seek?
[03:19:48] <cradek> no
[03:19:52] <cradek> no gcode is going to do an index seek in emc
[03:20:11] <Skullworks-PGAB> ok
[03:29:15] <steve_stallings> steve_stallings is now known as steves_logging
[03:49:28] <cradek> done
[03:51:37] <cradek> and goodnight
[14:13:19] <alex_joni> hrmm.. updated to latest TRUNK and after make it doesn't run for sim
[14:13:26] <alex_joni> will do a clean compil enext..
[14:17:38] <alex_joni> crap, same error..
[14:17:47] <alex_joni> does TRUNK sim run for any of you?
[14:20:17] <SWPadnos> I'll try it in a bit. what does it do to you?
[14:20:52] <alex_joni> it fails creating shm for the toolSts channel
[14:20:56] <alex_joni> and io craps out
[14:21:17] <alex_joni> * alex_joni restarts the VM.. might be soem laftover shm
[14:21:22] <SWPadnos> 64-bit or 32-bit?
[14:21:25] <alex_joni> some leftover shm
[14:21:26] <alex_joni> 32bit
[14:21:30] <SWPadnos> ok
[14:23:04] <alex_joni> ok, a restart made it work again
[14:23:09] <alex_joni> probably some forgotten shm's
[14:25:09] <jepler> it sure wouldn't hurt to take a look at removing all shm segments either before emcsvr is started or after it's stopped during shutdown
[14:30:00] <alex_joni> jepler: I am looking at adding support to read/change variables from the var file
[14:30:17] <alex_joni> am I correct that atm AXIS doesn't have any support for this?
[14:30:47] <SWPadnos> ouch. I think that'll be a major concurrency problem (from all the talk I've seen about it)
[14:31:12] <alex_joni> SWPadnos: nope
[14:31:17] <alex_joni> I want to implement it through task
[14:31:21] <SWPadnos> great :)
[14:31:22] <alex_joni> no direct access
[14:31:29] <alex_joni> and remove the direct-access from tkemc
[14:32:19] <SWPadnos> ah - that's the key. I thought there were multiple holders of the information, but I didn't realize that it was 1 copy for the EMC core, and other random copies for UIs and that sort of thing
[14:32:39] <alex_joni> actually it's a file
[14:32:45] <alex_joni> which EMC reads and maintains
[14:32:51] <alex_joni> but tkemc sometimes opens it directly
[14:32:56] <alex_joni> then tells emc to re-read
[14:33:02] <alex_joni> which only leads to trouble imo
[14:33:12] <alex_joni> plus it makes remote-UI a problem
[14:33:28] <SWPadnos> isn't the gile loaded into an internal array/buffer, and "periodically" written out?
[14:33:32] <SWPadnos> s/gile/file/
[14:34:11] <alex_joni> it gets written out from time to time
[14:34:13] <SWPadnos> of course - it's ASCII in the file and floats internally
[14:34:39] <SWPadnos> right - I know it's a file, but that's not the form that's used internally
[14:35:21] <SWPadnos> which means that the internal form and the persistent form need to be synchronized from time to time
[14:35:40] <alex_joni> right
[14:35:45] <alex_joni> latest at shutdown
[14:35:52] <SWPadnos> anyway - I think your approach is a good one. are you planning on adding NML commands to get/set vars? (or using any that may already exist)
[14:36:04] <alex_joni> yes
[14:36:10] <SWPadnos> cool.
[14:36:45] <alex_joni> first I'm studying the existing code for a while
[14:38:34] <SWPadnos> well, I see two major approaches - the simple one that would be easiest to write (EMC_NML_GET_VAR(int varnum, float *value) and corresponding SET message/function)
[14:39:18] <SWPadnos> and then there's the generic, discoverable, extensible one :)
[14:39:26] <jepler> variables don't only have numbers now, they have names
[14:39:37] <jepler> there are also scoped variables
[14:39:43] <jepler> what is the goal here?
[14:40:33] <SWPadnos> ok - names were another level up - something like GET_VAR_BY_NAME ...
[14:41:02] <SWPadnos> wait - which EMC parameters (from the .var file) are scoped?
[14:41:23] <SWPadnos> I should have used PARAM instead of VAR up there ...
[14:42:01] <jepler> SWPadnos: none of the things stored in the .var file are scoped
[14:42:08] <jepler> the var file can't store named variables either
[14:42:21] <alex_joni> jepler: in tkemc you can open a "variable editor"
[14:42:28] <SWPadnos> ok - it's those parameters we're talking about
[14:42:33] <alex_joni> which allows you to modify the var file directly
[14:42:40] <alex_joni> which is not good imo
[14:44:05] <alex_joni> jepler: I don't understand why AXIS parses the inifile in search of PARAMTER_FILE either
[14:45:10] <jepler> alex_joni: axis makes a copy of the var file. Otherwise, "previewing" a gcode file could change the "real" var file just as though the program got run
[14:45:51] <SWPadnos> that'll be a sticky problem, I think
[14:46:56] <alex_joni> jepler: I understand.. but I think this shouldn't be done through direct access to the file
[14:47:48] <SWPadnos> there would need to be checkpointing or the ability to explicitly change the parameter file (with separate get name, set name, file_read and file_write commands)
[14:48:38] <alex_joni> I think named vars don't get saved into the var file
[14:48:53] <jepler> alex_joni: you're right, there's no provision for them to be saved
[14:49:24] <alex_joni> not sure if that's a feature, but so far no-one complained about it
[14:49:44] <jepler> I am sure that few people even understand that they can change the .var file to have other numbered variables be saved
[14:49:50] <SWPadnos> the axis preview is actually a significant departure from the original EMC architecture - it essentially forks a separate interpreter for the preview, but needs to leave the state of the "real" EMC core alone
[14:49:52] <jepler> let alone wish that named variables could be saved
[14:50:10] <SWPadnos> I think Ken mentioned something about saving named parameters as "to be done later"
[14:58:59] <alex_joni> cradek: you increased the MAX Joints for XYZABCUVW ?
[14:59:59] <cradek> yes
[15:00:18] <SWPadnos> but it's not a power of 2 any more!
[15:00:25] <SWPadnos> at least it's a power of 3
[15:00:27] <alex_joni> cradek: cool
[15:00:46] <alex_joni> SWPadnos: you sounds like some manga episode
[15:00:54] <SWPadnos> !
[15:01:01] <SWPadnos> more power to me!
[15:01:20] <alex_joni> the power of 3 will not be defeated by evil
[15:01:26] <SWPadnos> heh
[15:03:06] <alex_joni> gantrykins + xyzabcuvw is so nice
[15:03:19] <alex_joni> * alex_joni wonders why we have trivkins
[15:06:11] <SWPadnos> alex_joni, have you ever heard ofa "delta pod"?
[15:06:18] <SWPadnos> I think that was the name of the macione
[15:06:21] <alex_joni> loadrt gantrykins [TRAJ]COORDINATES would do just fine
[15:06:22] <SWPadnos> machine
[15:06:29] <alex_joni> delta pod? doesn't ring a bell
[15:06:38] <alex_joni> still manga?
[15:06:42] <SWPadnos> I'll see if I can find a photo
[15:06:44] <SWPadnos> no :)
[15:07:12] <alex_joni> http://www.deltaenvironmental.com/ecopod.asp ?
[15:07:20] <SWPadnos> I visited the Delta Tau booth at Semicon, and they hada robot that was similar to a hexapod, but used parallel struts for each of 3 legs
[15:08:04] <SWPadnos> the manupulator platform always remained parallel to the base plane (the base was above the manipulator), but otherwise it's a lot like a Stewart platform)
[15:08:07] <SWPadnos> only 3 axis though
[15:08:16] <SWPadnos> 3 DOF, that is
[15:10:44] <SWPadnos> incidentally, something I found when at semicon was that more or less all of the manufacturers of machine controllers seem to have a $2000 unit
[15:11:14] <SWPadnos> and the delta tau has user-definable kinematics (though I'm not positive that's in the $2k model)
[15:23:54] <tomp> look at tri-a-glide, there's other machines, very fast pick and place http://www.parallemic.org/WhosWho/Companies/Profile001.html
[15:24:26] <SWPadnos> yep - that's the type of machine I saw. thanks
[15:24:27] <alex_joni> there's one called a flexpicker from abb
[15:24:36] <tomp> http://robotool.ifw.uni-hannover.de/pages/maschinen_pages/mikronTriaglide.html
[15:24:42] <SWPadnos> Delta Tau probably just called a Delta Pod for marketing reasons :)
[15:25:00] <SWPadnos> though theirs had fixed struts
[15:25:03] <alex_joni> http://www.globalspec.com/FeaturedProducts/Detail/ABBRobotics/IRB_340_FlexPicker_Parallel_Arm_Robot/19084/0
[15:25:15] <alex_joni> 150 picks / minute
[15:25:32] <SWPadnos> that's kind of slow
[15:25:38] <alex_joni> you think?
[15:26:00] <SWPadnos> 150/min is only 9000/hour, and I know older Fuji machines could do 18k parts/hour
[15:26:10] <SWPadnos> but if that's per manipulator, it may be very good
[15:26:23] <SWPadnos> (I think the Fujis had 3 or 6 heads)
[15:26:25] <alex_joni> that's picking it up and placing it somewhere
[15:26:31] <alex_joni> this is big, not for SMD parts
[15:26:38] <SWPadnos> ah
[15:26:42] <alex_joni> http://www.robots.com/movies.php?tag=97
[15:28:06] <tomp> hexaglide was the name i originally encountered, from 'indoor flyer' site http://www.ifr.mavt.ethz.ch/publications/honegger98b.pdf i was looking for edm oprbiting head, and was pointed to this device used by AGie WEDM heads to taper.
[15:28:28] <SWPadnos> the Delta Tau unit was cool - each strut had a joint similar to a luxo lamp, and the tor would change the effective length just by rotating the shoulder outward, so the elbow would have to bend in (and the wrist), effectively shortening the strut length
[15:28:38] <SWPadnos> s/tor/motor/
[15:29:21] <alex_joni> SWPadnos: check out the movie I posted..
[15:29:49] <SWPadnos> yep - that's the construction
[15:29:57] <SWPadnos> except for the rotator (which is neat)
[15:31:05] <SWPadnos> in that video, it doesn't look like it maintains parallelism
[15:31:12] <alex_joni> it does
[15:31:14] <SWPadnos> but it could be me :)
[15:31:25] <alex_joni> there are longer movies on abb's site
[15:38:32] <tomp> another form is a delta mechanism http://www.csem.ch/detailed/a_611-microdelta.rm
[15:38:54] <tomp> http://www.csem.ch/detailed/a_611-microdelta.htm
[15:40:46] <alex_joni> haha large working space (200 mm x 200 mm x 50 mm)
[15:42:05] <jmkasunich> ;-)
[15:42:10] <tomp> so you dont run out of room right away at that speed ;)
[15:42:12] <alex_joni> SWPadnos: some nice videos : http://www.abb.com/Product/seitp327/262ce7c337e2b552c12570c9003ff7e6.aspx
[15:42:33] <alex_joni> hi jmk
[15:43:20] <tomp> is center strut just air pots?
[15:43:37] <jmkasunich> hi alex
[15:43:41] <alex_joni> tomp: for rotation
[15:44:54] <jmkasunich> oh, with U-joints at top and bottom
[15:48:30] <alex_joni> http://library.abb.com/GLOBAL/SCOT/scot241.nsf/VerityDisplay/E3C20F5D647C80E3C1256B4B0044108B/$File/IRB%20340%208%20in%20a%20row%20Mildred.mpg
[15:56:11] <cradek> jepler: I like these touch-off changes
[15:56:23] <cradek> jepler: thanks for uncrapping it
[15:57:28] <cradek> jepler: hmm on the dialog could you make it have P1...G54 etc, like the menus? I suspect nobody knows what "P7" is without really thinking about it
[15:57:36] <SWPadnos> tomp, that delta mech is what I saw, though it was bigger
[15:58:09] <SWPadnos> I don't know what P7 is even with thinking about it :)
[15:58:42] <cradek> I bet that's why people want to use the gui to avoid using MDI G10
[16:00:01] <alex_joni> hrmm.. is there any reason why a printf doesn't show up in the console with sim?
[16:00:16] <cradek> no, I do that all the time
[16:00:27] <cradek> did you compile?
[16:00:38] <alex_joni> yeah
[16:01:31] <alex_joni> there was some problem with time/date.. so I'm doing a clean build now
[16:07:19] <tomp> alex_joni: mmmmm gipels cool movie,.
[16:15:59] <alex_joni> cradek: I think I nailed it, can you take a look?
[16:16:24] <SWPadnos> well duh. if I had just searched for "delta robot" first, it would have been easy :) http://www.parallemic.org/Reviews/Review002.html
[16:18:12] <alex_joni> pastebin.ca/646484
[16:32:47] <tomp> a reverse delta used as 3D input device ( half of a waldo ) http://www.indoor.flyer.co.uk/kinematics.htm
[16:40:30] <alex_joni> hmm.. this is interesting: http://www.indoor.flyer.co.uk/kinematic.pdf
[16:42:32] <SWPadnos> that's Graham Stabler's site, isn't it?
[16:43:04] <tomp> yeh, he began to build some. he told me AGie uses them for uv heads on wedm
[16:43:13] <SWPadnos> Mach has "equations" that you can use to generate motor positions. I think you have to write VB code to make the DRO show the world coordinates
[16:43:52] <tomp> joint to axis? mach displays joint?
[16:44:01] <SWPadnos> hmmm. nope - it displays world only
[16:44:08] <SWPadnos> (inthe PDF anyway)
[16:44:43] <alex_joni> and you can only jog in joint
[16:44:47] <SWPadnos> it appears that there's no joint limiting
[16:44:58] <SWPadnos> joint velocity / accel limiting, that is
[16:45:15] <SWPadnos> Now the x and y DROs will react as expected as will the feed rate as long as the A and B axis can keep up.
[16:45:22] <SWPadnos> ^^^ from the PDF
[17:09:24] <alex_joni> may I grumble about task?
[17:09:43] <jmkasunich> sure, grumble away
[17:09:48] <alex_joni> it sucks :D
[17:15:31] <SWPadnos> c'mon - you can grumble better than that!
[17:17:42] <alex_joni> it's not fun to try to see things with DEBUG=0xffff
[17:18:20] <SWPadnos> grep may be your friend, but sadly is needs you to know what you're looking for before it can find it :)
[17:18:29] <alex_joni> yeah
[17:50:40] <alex_joni> argh.. this is so frustrating
[19:26:31] <alex_joni> YAY!!!
[19:26:39] <alex_joni> it only took 4 hours to track this down
[19:26:49] <SWPadnos> heh
[19:27:00] <alex_joni> now another half an hour to remove printf's
[19:27:15] <SWPadnos> heh^2
[19:28:24] <alex_joni> * alex_joni wonders how he ended up fixing bugs in task
[19:30:09] <cradek> what did you fix?
[19:30:16] <alex_joni> the step gets stuck
[19:30:18] <SWPadnos> the problem
[19:30:37] <alex_joni> http://sourceforge.net/tracker/index.php?func=detail&aid=1680007&group_id=6744&atid=106744
[19:32:03] <cradek> alex_joni: you're my hero for fixing task problems
[19:32:36] <alex_joni> lots of heroes around
[19:32:46] <alex_joni> jepler is the ultimate one for doing docs work
[19:32:51] <cradek> only you (task) and jepler (lyx documentation)
[19:32:55] <cradek> yep :-)
[19:33:19] <alex_joni> you qualify for tp work :P
[19:34:18] <cradek> nah, I threw it out and rewrote it - nothing heroic about that :-)
[19:34:48] <SWPadnos> heh
[19:36:15] <alex_joni> hope I limited the number of new bugs I introduced with my fixes to under 10
[19:37:32] <SWPadnos> jmkasunich, that A/D is one chip I want to be able to support with my SPI implementation
[19:37:37] <SWPadnos> (for the mesa)
[19:38:00] <jmkasunich> generic spi is gonna be "fun"
[19:38:26] <jmkasunich> the spi logic might be generic, but the hal driver certainly needs to know what its talking to
[19:38:42] <SWPadnos> yeah. I've been thinking about it a bit, and I see that at minimum, there needs to be a separate SPI clock source and input, output, and I/O modules
[19:39:00] <SWPadnos> I/O may be doable as just an I and O block
[19:39:06] <SWPadnos> yes
[19:39:36] <jmkasunich> I would think that "spi" could include clock and data lines in one module
[19:39:51] <SWPadnos> only if you make the number of data channels a parameter
[19:40:36] <SWPadnos> the idea is that something like that chip, or a dozen separate ones using a single clock, can work with different data words (parallel serial data connections :) )
[19:41:02] <jmkasunich> I know - I was planning on one clock and N datas for my N single channel converters
[19:41:08] <SWPadnos> yep
[19:41:22] <SWPadnos> so either a parameter for the number of ins and outs, or separate blocks
[19:41:47] <SWPadnos> dunno which is worse to code - probably a single unit with multiple data channels is easier
[19:41:58] <jmkasunich> hard to say
[19:42:07] <jmkasunich> I haven't looked closely at generic SPI
[19:42:19] <jmkasunich> I picked out an A/D and D/A that were compatible in terms of waveforms
[19:42:36] <jmkasunich> both need 16 clocks with a select that goes active once per transfer
[19:42:47] <SWPadnos> in terms of implementing it in an FPGA, I suspect that a monolithic approach is easier (like software, where defining interfaces gets buys you nothing in the short term)
[19:43:25] <SWPadnos> yep - the data word size needs to be definable - some 16-bit chips take a 24-bit word that includes address info and other stuff
[19:43:40] <SWPadnos> (the AD5764C is a quad 16-bit DAC that does that)
[19:45:52] <SWPadnos> my "good design approach" thought was to have a module that generates the clock and a "word sync" signal - each of data shifters would then have outputs like chip select that would be active for as long as they're shifting data
[19:46:19] <SWPadnos> they would all start at the same time, but possibly finish at different times depending on word size
[19:46:33] <jmkasunich> separate word shifters for the varying word lengths?
[19:47:10] <SWPadnos> each data channel is a shift register (clocked by the clock module), a data register (possibly double-buffered), and a control word
[19:47:24] <SWPadnos> plus some other control lines to the outside world, most likely
[19:47:52] <SWPadnos> thisis what I hope to implement on an airplane with a laptop this week :)
[19:47:59] <jmkasunich> heh
[19:48:00] <SWPadnos> or at least get started
[19:48:10] <jmkasunich> I'm going for kiss
[19:48:27] <jmkasunich> supporting only specific devices
[19:48:33] <SWPadnos> well, I have a paying customer that will need this stuff, so this is y job for the next month or so
[19:48:40] <SWPadnos> s/y/my/
[19:48:45] <jmkasunich> and doing some other stuff in HW that is device specific
[19:48:54] <jmkasunich> for example, the A/D will sample at or close to 1MHz
[19:48:57] <jmkasunich> way to fast for the PC
[19:49:15] <jmkasunich> but the FPGA is going to be aware that its a 12 bit A/D, not a generic SPI thing
[19:49:26] <SWPadnos> I can get us something more generic, which hopefully won't take many more resources than the simple inflexible approach
[19:49:27] <jmkasunich> so it will keep a running sum of samples and running count of samples
[19:49:27] <SWPadnos> sure
[19:50:01] <jmkasunich> that makes it pretty easy for the driver to do block averaging over whatever the drivers sample rate is (some KHz, not Mhz)
[19:50:06] <SWPadnos> yep - I was thinking that the A/D interface would have a parallel data bus, which the SPI poert would convert to serial
[19:50:13] <jmkasunich> greatly reduces the anti-alias filter requirements
[19:50:15] <SWPadnos> a parallel port would add R/W signals, etc.
[19:51:36] <SWPadnos> I guess I need to know soon if I'm trying to bite off something waaaaaaaay bigger than I can do in the time allotted :)
[19:52:06] <jmkasunich> what is your customer doing with this?
[19:52:11] <jmkasunich> or is that a secret?
[19:52:12] <SWPadnos> PID
[19:52:15] <SWPadnos> :)
[19:52:21] <SWPadnos> it's a big-ass power supply for ECM
[19:52:28] <jmkasunich> ok
[19:52:39] <jmkasunich> to be perfectly honest, I'd aim for simple and specific
[19:52:43] <SWPadnos> gotta do waveforms and that kind of thing
[19:53:04] <SWPadnos> yeah, I may end up doing that. as I said - quick and dirty is generally much better in the short term
[19:53:30] <SWPadnos> the customer did make one tactical error though - they said "price is no object at this point" in my presence :)
[19:53:42] <jmkasunich> the infrastructure that I've been trying to do should allow simple and specific modules to be added to the generic driver
[19:54:13] <SWPadnos> doesn't the stepgen have a single timebase and multiple output oprts?
[19:54:17] <SWPadnos> ports
[19:54:19] <jmkasunich> I'd rather add modules like "AD7656" to it
[19:54:28] <jmkasunich> instead of having an "SPI" module
[19:54:31] <SWPadnos> sure - that makes sense
[19:54:46] <SWPadnos> but there is still a need for synchronization across modules
[19:54:57] <SWPadnos> s/is/may be/
[19:55:00] <jmkasunich> right - pwmgen is a better example,
[19:55:06] <jmkasunich> stepgen doesn't really share anything
[19:55:09] <SWPadnos> ok
[19:55:30] <jmkasunich> but for a pwmgen, generating the "triangle" or other carrier is non-trivlal gate-count, and wants to be shared
[19:55:48] <SWPadnos> if I have two of these chips, I want the sampling and clocking to be synchronous regardless of gate count
[19:56:11] <SWPadnos> that is probably doable by sharing the reset lines or having a "global reset" capability
[19:56:30] <jmkasunich> shared clock and chip select, individual data lines
[19:56:31] <SWPadnos> but it seemed that factoring out the clock and word controller would be better
[19:56:38] <jmkasunich> at least thats the approach I'm aiming for
[19:56:45] <SWPadnos> yeah
[19:57:04] <SWPadnos> on the ADS1100 (?) series, there aren't as many control pins to deal with
[19:57:16] <jmkasunich> even for the 5i20, I/O pins are a more constrained resource than gates anyway
[19:57:27] <jmkasunich> for the 5i22 its even more extreme
[19:57:35] <SWPadnos> heh
[19:57:42] <jmkasunich> oh, there are parallel I/O pins?
[19:57:51] <jmkasunich> control pins I mean
[19:57:52] <SWPadnos> yeah - like I said before, 7.5x the number of gates, only 1.33x the number of pins
[19:58:10] <jmkasunich> I've been looking at devices that have only clock, data, and chip select
[19:58:14] <SWPadnos> CS, conversion start, standby if desired ...
[19:58:30] <SWPadnos> right - most devices allow you to start a conversion on the firs tclock edge
[19:58:55] <SWPadnos> the 7656 is also parallel capable
[19:59:30] <jmkasunich> heh, 64 lead package
[20:00:03] <SWPadnos> unfortunately, I don't think the board I'm making will be usable in the machining world, but with some additional protection (isolation, input buffers, etc), it may be
[20:00:19] <SWPadnos> yeah - 64 leads, 1cm square :)
[20:00:22] <jmkasunich> to be honest, the machining world probably doesn't need 15 bit
[20:00:51] <SWPadnos> this chip isn't much more expensive than 14-bit, or 12-bit bipolar
[20:01:17] <SWPadnos> though there are an additional 2 channels that most people wouldn't need, so the per-used-channel cost is higher
[20:01:39] <jmkasunich> for machining, most people don't use A/Ds at all
[20:01:50] <jmkasunich> DAC + encoder is the mainstream servo arrangement
[20:01:57] <SWPadnos> true
[20:02:21] <SWPadnos> the board will have both directions, so again, it's going to be more expensive than needed in this realm
[20:02:40] <SWPadnos> it will be neato for HAL - imagine what halscope will be able to do :)
[20:02:53] <jmkasunich> the plan is that the board will have a 50 pin connector on one end that mates to a 5i20?
[20:02:56] <SWPadnos> (assuming some buffering in the FPGA)
[20:03:06] <SWPadnos> one or two 50-pin connectors
[20:03:18] <jmkasunich> halscope would have to be heavily revised if there is buffering
[20:03:22] <SWPadnos> and screw terminals
[20:03:23] <SWPadnos> yes
[20:03:30] <jmkasunich> right now it assumes that the timebase = the code execution rate
[20:03:41] <jmkasunich> I ain't touching that change
[20:03:47] <SWPadnos> heh
[20:04:12] <jmkasunich> after all, every other signal in the HAL will still be limited to the thread rate
[20:04:19] <SWPadnos> it will be easier if the requested addition of save/load is done
[20:04:36] <jmkasunich> I don't see that as making a difference
[20:04:49] <jmkasunich> halscope lets you look at any hal thing, once per thread run
[20:05:10] <jmkasunich> what you are describing would be used to look ONLY at external signals, at MUCH more than once per thread run
[20:05:17] <jmkasunich> not compatible
[20:05:40] <jmkasunich> although you could start with halscope's code and hack it to work as a soft oscilliscope
[20:05:40] <SWPadnos> halscope would only need to be used as the display / UI - something similar to halsampler can be the data source
[20:05:53] <SWPadnos> save/load decouples the data from theRTenvironment, and that's lots of the work
[20:06:08] <jmkasunich> now I'm really confused
[20:06:22] <jmkasunich> I don't know what you are thinking with this scope thing
[20:06:27] <SWPadnos> just an aside, really
[20:06:59] <SWPadnos> halscope, the user app, isn't RT at all, so replacing scope_sampler with something else shouldn't be much of an architectural change to halscope (the app)
[20:07:00] <jmkasunich> if its is "halscope", that means that it can capture any HAL variable (some of which might represent outside analogs), and ALL channels would be in sync, both internal and external ones
[20:07:10] <SWPadnos> yes
[20:07:59] <jmkasunich> if you replace the RT part with something that acquires 100 samples every time it runs, instead of just one, it certainly could be used as a faster scope
[20:08:07] <jmkasunich> but it couldn't be used to look at other stuff
[20:08:08] <SWPadnos> it should be possible to make something that can mark regions of samples as having been between HAL thread runs
[20:08:36] <jmkasunich> it would either be a memory hog, or have very short record lengths
[20:08:38] <SWPadnos> ie, writes to a register on the FPGA generate a timestamp, which can later be compared to sample times
[20:08:57] <jmkasunich> if the A/D rate is 20x the hal rate, you need 20x the memory depth to capture the same time interval
[20:09:02] <SWPadnos> it would certainly be a memory hog on the FPGA
[20:09:04] <SWPadnos> yep
[20:09:10] <SWPadnos> or 1/20 the time
[20:09:17] <jmkasunich> so either you capture far fewer HAL samples, or craploads of external samples
[20:09:29] <SWPadnos> anyway - that's a diversion - we don't need to confuse things with that at the moment
[20:09:34] <jmkasunich> true
[20:09:46] <jmkasunich> there are already software based analog scopes out there anyway
[20:09:51] <SWPadnos> yep
[20:10:02] <alex_joni> ROFL - topgear is soo funny
[20:10:09] <SWPadnos> faster than 250 KHz too, but probably not at 6 channels/16 bits
[20:10:09] <jmkasunich> topgear?
[20:10:15] <SWPadnos> british TV show
[20:10:21] <SWPadnos> usually about fast cars and stuff
[20:10:27] <alex_joni> this time about tractors
[20:10:42] <SWPadnos> heh - have you seen the Toyota Hi-Lux episode?
[20:11:01] <jmkasunich> SWPadnos: few scope applications ever need (or can use) 16 bits
[20:11:14] <jmkasunich> granted, halscope has a lot more dynamic range than most scopes
[20:11:21] <SWPadnos> heh
[20:11:51] <alex_joni> http://www.youtube.com/watch?v=UgdjK_z5E14
[20:12:23] <SWPadnos> I can only go from 500 ps to 50 seconds / div horizontal. for shame
[20:12:41] <jmkasunich> I was referring to vertical
[20:13:19] <SWPadnos> yeah - 20 mV to 50V is pretty low compared to nano to mega-units
[20:13:27] <SWPadnos> (and beyond)
[20:13:53] <jmkasunich> alex_joni: wtf are they blowing up?
[20:14:11] <alex_joni> they are plowing
[20:14:19] <jmkasunich> with explosives?
[20:14:26] <alex_joni> using dinamite to get it done faster
[20:14:53] <alex_joni> jmkasunich: like I said.. crazy.. btu funny
[20:15:06] <alex_joni> I love when he drives that monster tractor to town
[20:15:22] <jmkasunich> just got to that part
[20:15:34] <jmkasunich> its not really that big
[20:15:38] <alex_joni> love the yellow tractor
[20:18:29] <alex_joni> ROFLMAO http://www.youtube.com/watch?v=YvYoWoDoh_Q&mode=related&search=
[20:18:39] <alex_joni> that's a drag race
[20:20:33] <jmkasunich> http://www.youtube.com/watch?v=0EeHqED4kSg
[20:20:45] <jmkasunich> that will move more than the farm tractors
[20:21:45] <jmkasunich> hmm, long strings of driverless vehicles are a bit unstable
[20:21:55] <alex_joni> any idea when 'outgoing motion' is < 0 ?
[20:22:15] <cradek> mdi?
[20:22:25] <alex_joni> jmkasunich: the middle tractor is like the D11 you pasted
[20:22:29] <alex_joni> but way bigger
[20:22:37] <jmkasunich> the D11 is bigger you mean?
[20:22:50] <alex_joni> no, way smaller
[20:22:55] <jmkasunich> not bloody likely
[20:23:02] <alex_joni> the one the guy rode into town was also with tracks
[20:23:06] <alex_joni> but had 4 tracks
[20:23:11] <alex_joni> and hydraulic articulation
[20:23:17] <alex_joni> 24t weight
[20:23:37] <jmkasunich> cat D11 112t
[20:23:47] <alex_joni> really?
[20:23:51] <jmkasunich> yep
[20:24:04] <jmkasunich> its the size of a small house
[20:24:15] <jmkasunich> I once got to drive a D7
[20:24:25] <jmkasunich> stood next to a D10 - it was huge
[20:24:47] <jmkasunich> D11 is even bigger - 2nd biggest dozer in the world
[20:24:58] <alex_joni> komatsu 575A-2 ?
[20:25:01] <jmkasunich> yeah
[20:25:41] <skunkworks_> my uncle has a few crawlers. 2 d9 and some smaller ones.
[20:25:46] <skunkworks_> older
[20:26:52] <skunkworks_> father finally sold this http://www.electronicsam.com/images/ebay/MVC-165V.MPG
[20:27:09] <skunkworks_> it was nice to have - had a backhoe that we had mounted to it also.
[20:30:09] <Skullworks-PGAB> Alex - smack down http://www.youtube.com/watch?v=4-DGMrLGnLg&mode=related&search=
[20:31:36] <jmkasunich> http://www.youtube.com/watch?v=0EeHqED4kSg
[20:31:46] <jmkasunich> half way thru they flatten a pickup
[20:32:52] <skunkworks_> jmkasunich: I think that was the d11 video again.
[20:33:10] <jmkasunich> http://www.youtube.com/watch?v=zlykNYrxoQA&mode=related&search=
[20:33:13] <jmkasunich> sorry bout that
[20:33:24] <jmkasunich> darned clipboard
[20:33:52] <skunkworks_> no problem. ;0
[20:33:55] <skunkworks_> ;)
[20:36:30] <Skullworks-PGAB> but this is a local drive for me... http://www.youtube.com/watch?v=foHRK73uG6M
[20:36:54] <Skullworks-PGAB> ( I was there to watch )
[20:37:45] <alex_joni> Skullworks-PGAB: in the videogame?
[20:37:53] <Skullworks-PGAB> In fact I made the interior camera mounts for there 1990 run
[20:38:07] <Skullworks-PGAB> no On Pikes Peak
[20:38:37] <Skullworks-PGAB> they had 2 Bell Jet ranger helicopters chasing him to film
[20:39:18] <Skullworks-PGAB> but @ 12-14,000 ft they can't keep up so they had to leapfrog
[20:39:47] <Skullworks-PGAB> go straight up the side of the mountain and catch him coming out of the next urn
[20:42:30] <Skullworks-PGAB> http://www.youtube.com/watch?v=e-wMMKKoVKA&NR=1
[20:43:39] <Skullworks-PGAB> I went to the race 12 years in a row - then had to be out of state for a wedding...
[20:48:43] <jmkasunich> http://www.youtube.com/watch?v=t9WSHS67zn4&mode=related&search=
[21:03:47] <alex_joni> what is M0 ?
[21:04:02] <alex_joni> isn't that stop ?
[21:06:53] <skunkworks_> program stop
[21:09:15] <alex_joni> * alex_joni wonders why it shows up under active M-codes
[21:11:25] <skunkworks_> in axis - it actually pauses the program so you can start where you left off.. (which is what I am used to)
[22:27:26] <alex_joni> argh.. I don't understand this
[22:29:57] <SWPadnos> what?
[22:30:05] <alex_joni> you don't want to know :P
[22:30:09] <SWPadnos> true
[22:30:12] <alex_joni> http://sourceforge.net/tracker/index.php?func=detail&aid=1735431&group_id=6744&atid=106744
[22:31:52] <SWPadnos> hmmm
[22:32:43] <SWPadnos> does verify have the same kind of "branch" problems that axis "preview" brings up? (like vars / modal words being set in verify and not getting unset later)
[22:32:47] <SWPadnos> or would that be unrelated?
[22:33:04] <alex_joni> no, it actually tells task to run the file
[22:33:10] <alex_joni> but discards the output from the interpreter
[22:33:32] <SWPadnos> does verify do a program reset at the end?
[22:33:41] <alex_joni> the odd thing is this:
[22:33:49] <alex_joni> verify then run works
[22:33:58] <alex_joni> verify then step works strangely
[22:34:01] <SWPadnos> ok, just not step
[22:34:07] <alex_joni> but step is implemented as run, then set some falgs
[22:34:13] <SWPadnos> doesn't "run" reset the program first though?
[22:34:16] <alex_joni> flags even
[22:34:28] <SWPadnos> err - ok. I don't understand that :)
[22:34:33] <alex_joni> 'step' is implemented internally as a call to 'run'
[22:35:22] <SWPadnos> and diffing debug=0xFFFF logs doesn't turn up enough signal to overvcome the noise?
[22:35:32] <SWPadnos> overcome
[22:35:33] <alex_joni> the odd thing is with step is that interp reads through the whole file then starts executing
[22:35:54] <SWPadnos> hmmm. is that regardless of whether verify has been run?
[22:36:01] <alex_joni> no, only after verify has been run
[22:36:09] <alex_joni> without the verify it works ok
[22:36:23] <alex_joni> btw, 'verify' is 'run' with startline -1 :)
[22:36:28] <SWPadnos> heh
[22:36:44] <alex_joni> really twisted way of thinking
[22:36:51] <SWPadnos> uh - yeah
[22:37:05] <alex_joni> not to mention the use of goto - label
[22:37:40] <SWPadnos> lots of stuff was done with the premise that (a) CPU cycles are expensive and (b) this needs to act just like a paper tape machine
[22:37:42] <alex_joni> which jumps out of an if () else statement
[22:37:57] <SWPadnos> that's relatively common, I think (for goto)
[22:38:13] <alex_joni> * alex_joni hates things like that
[22:38:38] <SWPadnos> it can make it harder to trace when looking at the code
[22:39:20] <alex_joni> yeah
[22:39:22] <SWPadnos> this is in motion (usrmotintf.*) ?
[22:39:37] <alex_joni> no, everything is in emctaskmain.cc
[22:39:41] <SWPadnos> ah - ok
[22:41:05] <SWPadnos> where's the place that run(-1) gets called to verify?
[22:42:33] <alex_joni> tkemc.tcl
[22:42:41] <alex_joni> it calls emc_run with -1 as the argument
[22:42:43] <SWPadnos> heh
[22:42:52] <SWPadnos> no wonder why I couldn't find it :)
[22:43:05] <alex_joni> emc_run is emcsh.cc with a call to sendProgramRun(-1) from shcom.cc
[23:21:06] <alex_joni> AARGH
[23:21:13] <SWPadnos> heh
[23:21:15] <alex_joni> it's not even a task issue
[23:21:22] <alex_joni> * alex_joni whines
[23:21:24] <SWPadnos> obviously, you're still looking at task code
[23:21:30] <SWPadnos> ooooh - not task, eh?
[23:21:36] <alex_joni> nope
[23:21:40] <SWPadnos> tkemc?
[23:21:43] <alex_joni> emcsh and tkemc updating
[23:21:44] <SWPadnos> emcsh?
[23:21:47] <SWPadnos> interesting
[23:22:03] <SWPadnos> (well, to me as an outside observer it's interesting. I'm sure to you it isn't)
[23:22:15] <alex_joni> well.. I hope I'm right about this one
[23:22:36] <SWPadnos> I'm assuming that it would act the same in mini
[23:22:36] <SWPadnos> ?
[23:22:42] <alex_joni> yes
[23:25:07] <alex_joni> dang I'm good :D
[23:26:23] <alex_joni> another one line fix, and 3 hours wasted :D
[23:28:45] <alex_joni> that's it for me today
[23:28:50] <alex_joni> good night guys
[23:28:56] <cradek> goodnight alex
[23:29:01] <cradek> thanks for all the fixes today
[23:29:13] <alex_joni> glad I can still do this :)
[23:32:49] <alex_joni> petev sure has a way catching odd bugs
[23:34:33] <skunkworks> if it is any consolation - I cought one of the bugs he introduced a few weeks back ;)
[23:34:57] <alex_joni> ha