Back
[00:16:25] <chinamill> * chinamill is away: fixing mill
[00:17:47] <rayh> quick note for the logger
[00:18:34] <rayh> we set up a rotary axis in HAL and EMC for chinamill and added a page to wiki
[00:35:10] <rayh> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?SampleParport
[00:35:21] <rayh> page needs a lot of editing and additions.
[02:26:16] <cradek> rayh: I didn't reply to your message but I think it's very good
[02:26:47] <rayh> Okay I'll send it soon.
[02:26:55] <rayh> thanks
[02:27:10] <cradek> oops, wrong channel
[02:27:11] <cradek> oh well
[02:27:27] <rayh> not a problem.
[02:27:37] <rayh> unless you are as old as I am.
[02:32:23] <alex_joni> probably the others have no idea what you are talking about :)
[02:47:57] <alex_joni> alex_joni is now known as alex_joni_away
[03:26:52] <alex_joni_away> alex_joni_away is now known as alex_joni
[03:36:05] <alex_joni> jmkasunich: join the board channel please ;)
[03:36:48] <jmkasunich> I did dammit (the old one ;-)
[03:37:09] <rayh> do that every time.
[03:37:51] <alex_joni> jmk: autojoin list ;)
[03:38:04] <alex_joni> I'll ask paul today if I find him
[03:38:10] <cradek> jmkasunich: is that bug in stepgen's accel that you found recently possibly causing my spurious joint following errors?
[03:38:22] <jmkasunich> I was trying to do something like that, either ksirc doesn't do it, or I'm too dense to figure it out
[03:38:38] <jmkasunich> cradek: could be
[03:38:42] <jmkasunich> easy to test
[03:39:07] <jmkasunich> somewhere in your hal file (core-stepper.hal I think) is a line like:
[03:39:27] <cradek> wait, I'm not there, I'll be there later
[03:39:29] <jmkasunich> setp stepgen.0.maxaccel [AXIS_0]MAX_ACCEL
[03:39:34] <jmkasunich> change it to:
[03:39:55] <jmkasunich> setp stepgen.0.maxaccel <some number that is about 5% higher than the inifile value)
[03:40:13] <cradek> oh, ok, that's easy
[03:57:10] <rayh> SWPadnos: morning.
[03:57:16] <SWPadnos> morning
[03:57:48] <rayh> I put one page of HAL tickle on linuxcnc.org this morning.
[03:57:54] <SWPadnos> so cradek gets "Chairman", and you get "Loudmouth" ;)
[03:58:02] <SWPadnos> ok - cool. I'll take a look
[03:58:20] <jmkasunich> what is hal tickle?
[03:58:27] <alex_joni> it's a virus
[03:58:35] <alex_joni> slowly taking over HAL :D
[03:58:45] <SWPadnos> it's what you get in your throat just before a cold ;)
[03:58:49] <jmkasunich> uh, oh
[03:58:54] <alex_joni> it's some tcl code ray did to show HAL status
[03:59:01] <jmkasunich> where?
[03:59:02] <rayh> www.linuxcnc.org/Dropbox/hal_show.tcl
[03:59:08] <alex_joni> to be able to do IOShow, or something like that.. right ray?
[03:59:12] <SWPadnos> I think the idea is to make a tuning app
[03:59:48] <rayh> I used a very rough draft of the front page about 4 this morning to get chinamill going
[03:59:54] <rayh> with a rotary 4th
[04:00:22] <jmkasunich> so where in my tree do I put it, and how do I invoke it?
[04:01:09] <rayh> in the emc2 directory and ./hal_show.tcl
[04:01:24] <jmkasunich> while emc is running I assume?
[04:01:29] <rayh> you'll need a running hal to get much out of it.
[04:01:36] <rayh> Way ahead as always.
[04:02:02] <SWPadnos> I'll take a look once (a) my coffee has brewed, and (b) I've booted the emc machine ;)
[04:02:25] <rayh> k
[04:02:31] <jmkasunich> eek... (mini scares me when it pops up over the whole screen ;-)
[04:02:34] <alex_joni> SWPampy: get that coffee already ;)
[04:02:45] <SWPadnos> it's brewing - you can't rush that
[04:02:56] <SWPadnos> (sadly)
[04:03:07] <rayh> I didn't think mini was an option in the emc.ini
[04:03:29] <jmkasunich> I have my sim.ini set up to run mini (don't recall why)
[04:03:38] <alex_joni> that's in CVS I think
[04:03:45] <SWPadnos> I think all the UIs work - it's backplot that had some weirdness in AXIS
[04:03:56] <alex_joni> must have been me.. when I added mini to emc2
[04:03:57] <alex_joni> :(
[04:04:06] <SWPadnos> ok - that could be
[04:04:16] <cradek> what's wrong with AXIS?
[04:04:34] <SWPadnos> way back, didn't you have to fix something to get it to work with emc2?
[04:04:55] <cradek> we've had to catch up with emc2 changes many times
[04:05:12] <jmkasunich> is
[04:05:14] <jmkasunich> oops
[04:05:15] <cradek> maybe I misunderstood - are you saying there's something wrong with it now?
[04:05:30] <jmkasunich> is "show_ HAL" the only window that works so far?
[04:05:48] <SWPadnos> nope
[04:05:54] <SWPadnos> nope to cradek
[04:06:05] <cradek> ok, forget I said anything
[04:06:15] <SWPadnos> no prob
[04:06:26] <rayh> Right jmkasunich
[04:06:59] <jmkasunich> halcmd without the typing!
[04:07:21] <rayh> But I was able to use it rather easily to illustrate how an axis (not the gui) pin can be followed through to signals
[04:07:48] <jmkasunich> yeah, having it right there makes it much easier to talk a person thru things
[04:07:49] <rayh> and how to model one axis pins and params to make another.
[04:08:34] <jmkasunich> are the screens live, or do you have to hit the show button to refresh (say after you've changed a param value, or added a signal)
[04:09:02] <rayh> the watch screen is intended to be live for the pins you select
[04:09:12] <jmkasunich> ok, the show screen is a snapshot
[04:09:25] <rayh> Yes. World view if you will
[04:09:41] <alex_joni> * alex_joni pays a visit to the doc
[04:09:43] <alex_joni> later guys
[04:09:44] <rayh> although if you enter iocontrol in the search and press pins you get only those.
[04:09:45] <jmkasunich> the file menu: what is that for?
[04:09:47] <jmkasunich> bye alex
[04:09:52] <jmkasunich> hope he can cure you
[04:09:53] <rayh> good luck
[04:09:57] <alex_joni> yeah.. thanks
[04:10:17] <jmkasunich> nice (the search)
[04:10:28] <jmkasunich> I can see me using this a lot
[04:10:28] <rayh> I'm working there toward reading hal files and editing to match config setup.
[04:10:51] <rayh> I need to pass an idea to you.
[04:10:51] <jmkasunich> you know about halcmd save don't you?
[04:11:15] <rayh> a separation between loadxx files and linkxx files
[04:11:15] <jmkasunich> (although that loses any comments in the original file, and doesn't handle insmod command line params)
[04:11:24] <jmkasunich> shoot
[04:11:41] <rayh> that's the idea I had.
[04:11:54] <jmkasunich> elaborate a little please?
[04:12:07] <jmkasunich> I think I know what you are talking about
[04:12:07] <rayh> It pretty much would hide the hal file that is run.
[04:12:21] <jmkasunich> ok, I don't know what you are talking about ;-)
[04:12:27] <rayh> we could issue the load commands from the ini file
[04:12:52] <jmkasunich> load what? a hal file?
[04:12:55] <rayh> then we can read, save, and run a hal file
[04:13:02] <rayh> from halcmd
[04:13:20] <rayh> no loadrt xxx
[04:13:34] <jmkasunich> oh
[04:14:10] <jmkasunich> not so much "no loadrt xxx" but "no loadrt xxx in the .hal files that connect everything together"
[04:14:25] <jmkasunich> you could have one hal file that just loads everything, invoke that one first
[04:14:25] <rayh> right.
[04:14:40] <jmkasunich> then invoke another(s) to do the config
[04:14:53] <rayh> yes and we could make a page just for it in the tickle
[04:15:05] <jmkasunich> you are working toward one .hal file for the entire configuration, aren't you?
[04:15:30] <rayh> right now i don't know how to do otherwise.
[04:15:40] <jmkasunich> (as opposed to core-servo.hal+ppmc-motion.hal+ppmc-io.hal+custom.hal)
[04:15:48] <rayh> within the hal_show context
[04:16:00] <rayh> yes.
[04:16:14] <jmkasunich> right now, each individual file adds something to the config
[04:16:30] <jmkasunich> but halshow can only show (and you can only save) the whole thing
[04:16:53] <jmkasunich> there are pros and cons to both approaches
[04:17:01] <rayh> The multiple file approach is easier to understand when you work directly from a text editor.
[04:17:15] <jmkasunich> the "sum of many configs" approach lets you use "standard" chunks
[04:17:31] <jmkasunich> the "all in one" approach makes file management easier
[04:18:02] <SWPadnos> there's another way to look at that
[04:18:40] <SWPadnos> when you load a module (at least the motion-related ones, like PID and the like), there are some connections that are very likely to be made
[04:18:42] <jmkasunich> hmmm, maybe we want to transition over to the all-in-one approach, but have a "new config" wizard that asks questions and loads some of the core files based on the answers....then saves the combined config for further tweaking
[04:18:51] <SWPadnos> like pid.0 inputs go to axis.0 outputs
[04:19:20] <jmkasunich> swp: yes, that was the intent of the core_xxx files
[04:19:34] <SWPadnos> right - they can only connect "upstream" by default
[04:19:49] <rayh> swp and I were talking about agregating pins into a plug the other day
[04:20:06] <SWPadnos> like a LabView bundle- if that helps
[04:20:24] <jmkasunich> not really, I'm aware of labview, but never used it
[04:20:52] <rayh> what I did with chinamill this morning would have been easy if there were a "axis" plug
[04:21:07] <jmkasunich> however, on the "someday" list for HAL, I was thinking of the ability to wrap a group of blocks and signals into a "megablock"
[04:21:15] <SWPadnos> you can basically have a signal that consists of a struct of other signals
[04:21:19] <rayh> exactly.
[04:21:43] <jmkasunich> rayh: which one did you "exactly" to?
[04:21:52] <rayh> jmk
[04:22:26] <rayh> I used the example of the lego blocks
[04:22:34] <rayh> to think about it.
[04:22:48] <jmkasunich> thing is, swp's approach would be prettier
[04:22:53] <rayh> all of these pins fit into all of these.
[04:23:11] <rayh> at what level do you see the pretty?
[04:23:15] <rayh> code
[04:23:17] <rayh> user
[04:23:24] <rayh> hal file
[04:23:38] <jmkasunich> my megablocks would still have individual pins at their border, and would still need to be conneted one-at-a-time to the next (mega)block
[04:23:52] <SWPadnos> sub-sheets with ports
[04:24:10] <jmkasunich> I was thinking sub-sheets, but not ports
[04:24:22] <SWPadnos> the ports are the exported pins (in Protel)
[04:24:31] <SWPadnos> external sheet connections
[04:24:40] <jmkasunich> and worse (depending on your point of view), once loaded, in halcmd it would still be flat
[04:24:43] <SWPadnos> ah -I see now
[04:25:00] <jmkasunich> are ports a single signal, or multiple?
[04:25:11] <SWPadnos> if you add a "subcomponent" field, you can get rid of all of them at once
[04:25:20] <SWPadnos> single pin (or bus, in the schematic model)
[04:25:30] <jmkasunich> ok, then with ports
[04:25:37] <SWPadnos> actually, a bus is similar to the bundle idea
[04:25:47] <jmkasunich> ( I thought maybe "port" was the "plug" thing you mentioned earlier)
[04:25:48] <SWPadnos> just with different types
[04:25:52] <SWPadnos> nope
[04:25:53] <jmkasunich> bus is homogenous
[04:26:40] <SWPadnos> well - you can have a bus with address and data pins, but you wouldn't usually group analog and digital llines ;)
[04:26:48] <jmkasunich> both in type, and in usage (usage is up to the guy drawing the schematic, but I for one never grouped things like rd strobes and wr strobes into a bus)
[04:27:14] <jmkasunich> I see busses as more like arrays than structs
[04:27:18] <SWPadnos> yep
[04:27:24] <SWPadnos> hence the "bundle" term
[04:27:26] <jmkasunich> your "plugs" are structs
[04:27:34] <SWPadnos> yes
[04:28:09] <jmkasunich> connecting plugs means verifying that their structs match
[04:28:24] <jmkasunich> would you require just a type match, or a name match
[04:28:28] <jmkasunich> I think name
[04:28:44] <jmkasunich> that is limiting tho
[04:28:55] <SWPadnos_> type only - there's no need to have names match now (using signals)
[04:29:27] <SWPadnos_> you don't automatically connect things (you meaning HAL)
[04:29:28] <jmkasunich> ok, if a plug has 3 analogs and 3 bits, how do you define which analog on one side connects to which on the other
[04:29:37] <SWPadnos_> analog 1 connects to analog 1
[04:29:42] <SWPadnos_> analog 2 to analog 2
[04:29:43] <SWPadnos_> etc.
[04:29:52] <SWPadnos_> they are structs, so they should match
[04:29:52] <jmkasunich> ok, so ordered by some number
[04:30:07] <SWPadnos_> yes - all connections are made / broken in one go
[04:30:08] <rayh> I thought of em as an array
[04:30:10] <jmkasunich> structs is just a concept, there are no actual C structs here
[04:30:17] <SWPadnos_> I understand
[04:30:17] <rayh> matching arrays
[04:30:19] <jmkasunich> so we have to define the order
[04:30:22] <SWPadnos_> just for discussion
[04:30:34] <SWPadnos_> arrays can only have one type, I
[04:30:34] <jmkasunich> ray: in C, arrays means a group of identical typed items
[04:30:47] <jmkasunich> you can have an array of bits, or an array of floats, but not a mixed array
[04:30:55] <jmkasunich> structs allow mixing
[04:31:00] <SWPadnos_> arrays can only have one type, I'm thinking of something that you could connect an enable and a float output togeher with
[04:31:02] <jmkasunich> so they are more appropriate here
[04:31:04] <rayh> I guess I'm still thinking geometry and the notion of plugs
[04:31:31] <rayh> antenna array not a c array.
[04:31:32] <SWPadnos_> sure - you take the nice MS circular connector and plug it into the correct socket
[04:31:46] <SWPadnos_> actually - any matching socket
[04:31:53] <rayh> Right and the rotation is handled by the index slide
[04:32:06] <jmkasunich> rayh: there are some physical plugs where not all pins are the same
[04:32:07] <SWPadnos_> yep -that's the "type" in this discussion
[04:32:14] <SWPadnos_> like the MS connectors
[04:32:26] <rayh> certainly
[04:32:29] <jmkasunich> skinny ones for logic, fat ones for power, maybe even coax ones for RF, all in one housing
[04:32:38] <jmkasunich> that's the model I have in my head
[04:32:39] <rayh> exactly
[04:32:49] <SWPadnos_> yes - and location is significant
[04:33:37] <rayh> My thought this morning was something like
[04:33:53] <jmkasunich> I was thinking that when you define a plug, you say: "plug pin <some-name> connects to signal <some-name>"
[04:33:56] <rayh> axis.3 ==> stepgen.3
[04:34:13] <jmkasunich> where axis.3 is a plug
[04:34:21] <SWPadnos_> right - jmk, the idea is to be able to plug groups of things all at once
[04:34:22] <jmkasunich> (and so is stepgen.3)
[04:34:28] <rayh> yep
[04:34:30] <jmkasunich> so how to define a plug
[04:34:39] <rayh> beats me.
[04:34:41] <SWPadnos_> that's a darned good question
[04:34:49] <SWPadnos_> that's your job ;)
[04:34:52] <jmkasunich> thats what I'm brainstorming
[04:34:57] <jmkasunich> we're brainstorming
[04:35:04] <SWPadnos_> oh - right
[04:35:05] <jmkasunich> within the plug are pins
[04:35:11] <SWPadnos_> well - you can take a cue from C++
[04:35:22] <jmkasunich> (plug pins, not hal pins - damn terminology)
[04:36:03] <SWPadnos_> the way that C++ keeps different versions of functions straight is by appending a string that tells the tpyes the function takes and returns
[04:36:23] <jmkasunich> I want more than just type matching
[04:36:30] <SWPadnos_> (I'm thinking about how to make them internally now, not the command interface)
[04:36:42] <jmkasunich> heh. command interface comes first
[04:36:46] <SWPadnos_> damn!
[04:36:53] <jmkasunich> define what you want to do, then figure out how to do it
[04:36:59] <SWPadnos_> ok - fine. I need more coffee then
[04:37:08] <jmkasunich> so, you wanna make a plug
[04:37:21] <SWPadnos_> you don't do that in halcmd, you do it in the component
[04:37:26] <SWPadnos_> hal_register_plug
[04:37:32] <jmkasunich> nope
[04:37:33] <SWPadnos_> hal_register_socket
[04:37:44] <rayh> I've got to get some lunch fixed for the grand kids.
[04:37:50] <jmkasunich> I want to be able to make these megacomponents out of stock HAL components
[04:37:52] <SWPadnos_> a likely story ;)
[04:37:55] <jmkasunich> not have special ones
[04:37:58] <rayh> I know you guys have this well in hand.
[04:38:12] <SWPadnos_> see ya "Official Loudmouth"
[04:38:16] <jmkasunich> bye ray
[04:38:40] <jmkasunich> SWP: something very scary is coming into my head
[04:38:53] <jmkasunich> hal with heirchary
[04:38:59] <jmkasunich> damn I hate that word
[04:39:00] <SWPadnos_> oooohhh - I like that
[04:39:02] <rayh> to bad I can't stay
[04:39:06] <SWPadnos_> hierarchy
[04:39:20] <SWPadnos_> (yes I know - damn me)
[04:39:26] <jmkasunich> something like this in a hal file:
[04:39:34] <jmkasunich> newblock {
[04:39:40] <jmkasunich> newsig blah
[04:39:45] <jmkasunich> newblockpin blah
[04:39:58] <jmkasunich> linksp <blockpin> <blocksig>
[04:40:17] <jmkasunich> lots of other links and sigs and such that are internal to the block
[04:40:20] <jmkasunich> }
[04:40:34] <jmkasunich> no, thats not right
[04:40:51] <jmkasunich> because a block will probalby need more than one plug
[04:40:54] <SWPadnos_> well - I think it's important to show things at the same level they're created
[04:41:21] <SWPadnos_> so if someone loads some block hal file, then they do halcmd show, they see that there's a block, and whatever it exports to the world
[04:41:28] <SWPadnos_> not the underlying complex stuff
[04:41:38] <jmkasunich> to do this right, we need to be able to instantiate a block (standard hal block) after the loadrt
[04:41:39] <SWPadnos_> you need to be able to get at that, but not by default
[04:41:54] <SWPadnos_> yes, and update multiple connections atomically
[04:42:14] <SWPadnos_> which all points to hallib
[04:42:46] <jmkasunich> and a helper thread in kernel space (to instantiate blocks on demand), or an ioctl, or a syscall, or something like that
[04:43:09] <SWPadnos_> btw - what fifo / queue functions are available between userspace and RT?
[04:43:26] <SWPadnos_> there's got to be a queue - motion uses that
[04:43:35] <jmkasunich> no it doesn't
[04:43:41] <SWPadnos_> fifo?
[04:43:49] <jmkasunich> it uses a single buffer at the RT/user boundary
[04:43:55] <jmkasunich> and queues inside RT
[04:44:03] <jmkasunich> (stupid I know)
[04:44:08] <SWPadnos_> does it poll?
[04:44:12] <SWPadnos_> the RT side
[04:44:29] <jmkasunich> the RT side is inherently periodic, so yes, it polls - it can't do anything else
[04:44:35] <SWPadnos_> ok
[04:44:55] <jmkasunich> anyway, look at rtapi.h for info about fifos
[04:45:18] <SWPadnos_> will do - AC (after caffeine)
[04:45:40] <jmkasunich> that documents and implements the functionaity that seemd to me to be the best common featureset between RTAI and RTLinux (as of the versions that existed at that time)
[04:46:29] <jmkasunich> DC (during caffeine)
[04:46:31] <SWPadnos_> ok - and if you still want to support those versions, then it means that's the way it has to stay
[04:46:36] <SWPadnos_> ok - I can do that
[04:46:45] <jmkasunich> unless we can find something I missed
[04:47:15] <SWPadnos_> I'm not the person to do that, unfortunately
[04:47:17] <jmkasunich> did you and/or petev find anything the other night?
[04:47:53] <SWPadnos_> I didn't (relative to the user <-> RT sepmaphores)
[04:47:59] <SWPadnos_> semaphores
[04:48:26] <jmkasunich> if both sides are polling, then you don't really need RTOS support for fifos
[04:49:02] <jmkasunich> just allocate some shmem, set up head and tail pointers and write thread-safe put_on_fifo() and get_from_fifo() cals
[04:49:08] <SWPadnos_> echo "show pin" /dev/hal && cat /dev/hal
[04:49:30] <jmkasunich> paul would shoot you
[04:49:32] <SWPadnos_> heh
[04:49:35] <jmkasunich> (and I might too)
[04:49:39] <jmkasunich> no parsing in kernel space
[04:49:55] <SWPadnos_> um - what about /proc/sys ?
[04:50:00] <jmkasunich> let user space (halcmd) parse, and then issue error-checked commands to kernel space
[04:50:32] <jmkasunich> drat
[04:50:34] <jmkasunich> /dev/hal ioctls, /proc/hal, all are possibilities
[04:50:43] <jmkasunich> must remember the leading space before /
[04:50:51] <SWPadnos_> heh - yep
[04:51:00] <jmkasunich> but not ascii commands to /dev/hal
[04:51:03] <SWPadnos_> dev/hal is not a recognized command
[04:51:10] <SWPadnos_> that's fine
[04:51:20] <jmkasunich> the problem is portability
[04:51:28] <SWPadnos_> I like the fifo / sem / mutex thing better anyway
[04:51:40] <SWPadnos_> /queue
[04:51:56] <jmkasunich> /dev is endangeded by new things like udef, sysfs, etc
[04:52:11] <SWPadnos_> sure, but an ini file parameter takes care of that for you
[04:52:17] <jmkasunich> ?
[04:52:25] <SWPadnos_> like specifying /dev/cdrom for k3b
[04:52:38] <jmkasunich> you lost me
[04:53:00] <SWPadnos_> the kernel module does whatever it needs to do, and the file node gets placed wherever that kernel wants it to be
[04:53:07] <jmkasunich> my understanding is that some newer systems might not have /dev at all
[04:53:22] <jmkasunich> they use udev or something else
[04:53:27] <SWPadnos_> userspace gets told where that is with a line in emc.ini like [EMC]CONTROL_FILE = /dev/hal
[04:53:39] <SWPadnos_> or [EMC]CONTROL_FILE = /udev/hal
[04:53:49] <SWPadnos_> or CONTROL_DEVICE
[04:53:55] <jmkasunich> but kernelspace needs to support all of those (I don't think they have a common interface)
[04:54:19] <jmkasunich> I'll be damned if I'm gonna learn and code for three differnet interfaces just because the kernel folks keep changing stuff
[04:54:20] <SWPadnos_> no - I think in kernelspace, you just register the major and minor number your driver handles
[04:54:27] <SWPadnos_> the userspace helpers create the device nodes
[04:54:36] <SWPadnos_> (mknod, udev, sysfs, whatever)
[04:54:45] <jmkasunich> obviously I don't know enough about these things ;-)
[04:54:48] <SWPadnos_> so it's distro-specific, not module-specific
[04:55:03] <SWPadnos_> I'm not speaking the gospel here, but I think that's how it works
[04:56:45] <jmkasunich> sorry, phone, back now
[04:56:57] <SWPadnos_> that's not the case with /proc entries though - the kernel module does create those by name (though /proc could be /systeminfo or whatever)
[04:57:05] <SWPadnos_> np - I actually got that coffee refill ;)
[04:57:32] <jmkasunich> if /dev/hal (or other flavors) can be done without too much nastyness I'm all in favor of that - it is more "by the book" than using a RT helper thread
[04:57:49] <SWPadnos_> hmmm
[04:58:11] <jmkasunich> same thing with /proc, although even that is a kernel option, you can build a box without a /proc filesystem
[04:58:20] <SWPadnos_> actually, there can be a group of proc entries - /proc/hal/pins, /proc/hal/sigs, etc
[04:58:27] <SWPadnos_> just cat that, snd you get your list
[04:58:39] <jmkasunich> and Paul has said that /proc is being phased out in favor of /sysfs
[04:58:54] <SWPadnos_> /whateverthenameisnow/hal/pins ...
[04:58:59] <jmkasunich> proc entries that return more than one page (about 4K) of data are nasty to code
[04:59:08] <SWPadnos_> yes -I was just about to mention that
[04:59:20] <jmkasunich> I'd still rather have an API, and let a user level library handle things
[04:59:28] <SWPadnos_> yes
[04:59:50] <jmkasunich> whateverthenameisnow will need differnet code to handle it
[05:00:00] <SWPadnos_> I think that a polling thread in kernel isn't that bad a performance hit. the only nagging problem is the latency from command to execution
[05:00:01] <jmkasunich> I have no systems with sysfs, no way to test it
[05:00:22] <jmkasunich> its a fatal performance hit for something like show pins
[05:00:56] <SWPadnos_> only if you have to poll for each pin
[05:00:59] <jmkasunich> because unless it can return an arbitrarly long list at once (which it cant), show involves a bunch of calls: get first, get next, get next, get next
[05:01:46] <SWPadnos_> you can have a command that asks for all pins, all pins matching a certain pattern (though regexp in kernel would likely be bad)
[05:01:54] <SWPadnos_> all pins with a certain owner ID
[05:02:00] <SWPadnos_> etc
[05:02:03] <jmkasunich> but how do you return that list to user space?
[05:02:17] <SWPadnos_> in a big buffer
[05:02:23] <jmkasunich> how big?
[05:02:28] <jmkasunich> and where? shmem?
[05:02:32] <SWPadnos_> this big > < ;)
[05:02:47] <jmkasunich> and what if two instances of halcmd are running at the same time? two buffers?
[05:02:57] <jmkasunich> (right now halcmd is thread safe)
[05:02:57] <SWPadnos_> well - that could be an issue
[05:03:15] <SWPadnos_> but if two instances are running, how would they keep nextpins separate?
[05:03:21] <SWPadnos_> nextpin calls, that is
[05:03:32] <jmkasunich> get_next(char *prev)
[05:03:53] <jmkasunich> each call is atomic, it actually looks up prev, then returns the next one
[05:04:15] <SWPadnos_> incidentally - this is only an issue if the helper services one request per polling cycle
[05:04:20] <jmkasunich> I plan to store the metadata in AVL trees instead of linear lists to speed the lookup, for exactly that reason
[05:04:29] <SWPadnos_> if it empties the queue, every time, then it's not so bad
[05:04:43] <jmkasunich> doesn't work
[05:05:15] <jmkasunich> the user prog puts get_first() in the queue... even if get_next() doesn't need the name of the previous one, how many should it queue?
[05:05:15] <SWPadnos_> why not (assuming that the result queue is as long as the command queue)?
[05:05:45] <jmkasunich> of course if get_next needs the name of the previous, you can't queue it until the previous call returns
[05:06:01] <SWPadnos_> ok - one other item that can be done (possibly) - once you get a command, have a shorter wait before the next poll cycle. if nothing is found, then wait a longer time
[05:06:22] <jmkasunich> a workaround, and maybe viable
[05:06:28] <jmkasunich> but still a hack
[05:06:55] <jmkasunich> I think I'd rather suffer thru /proc vs /sysfs, or /dev vs udev vs who knows what
[05:07:35] <SWPadnos_> actually - it's not that hard to add a syscall to the kernel
[05:07:43] <jmkasunich> there is no nice answer, which is why I've been avoiding it
[05:07:48] <SWPadnos_> emc already requires a patched kernel, why not add one more?
[05:07:51] <jmkasunich> do you have to recompile the kernel?
[05:07:57] <SWPadnos_> yes
[05:08:04] <jmkasunich> not an option then
[05:08:06] <SWPadnos_> but only if you don't have an emc kernel already
[05:08:09] <jmkasunich> I want to run on BDI-old
[05:08:16] <SWPadnos_> it's the same as now - you have to add the adeos patches
[05:08:28] <SWPadnos_> ah - the upgrade path
[05:08:32] <jmkasunich> we already have hundreds of people with patched kernels
[05:08:49] <jmkasunich> people who have not and will not patch themselves
[05:09:09] <SWPadnos_> (I don't like the patched kernel idea anyway, because I'd like to be able to run something without RT patches, for testing)
[05:09:15] <jmkasunich> right
[05:09:27] <jmkasunich> another reason the RT helper thread idea is less attractive
[05:09:38] <jmkasunich> /proc works regardless
[05:09:56] <jmkasunich> actually /dev is probably the right way to do it
[05:10:16] <jmkasunich> proc is nice because you don't need to mknod
[05:10:26] <SWPadnos_> yep - all you need is an alias-char-major haldev xxx in modules.conf
[05:10:31] <jmkasunich> but maybe ./configure could do the mknod
[05:10:57] <jmkasunich> I don't know anything about modules.conf
[05:11:03] <jmkasunich> (I should, but I dont)
[05:11:07] <SWPadnos_> or conf.modules ...
[05:11:43] <SWPadnos_> all it does is tell insmod what driver to load when a file request comes in on a device node with a certain major/minor number
[05:11:59] <SWPadnos_> (or tell what you mean by eth0, etc)
[05:12:08] <jmkasunich> oh....
[05:12:26] <jmkasunich> I would keep the "realtime start" model, explicitly load the driver module and keep it loaded
[05:12:31] <SWPadnos_> well - it may do more, but that's the extent of my knowledge about it
[05:13:33] <jmkasunich> * jmkasunich googles
[05:13:51] <SWPadnos_> way ahead of you ;) (googling sysfs, that is)
[05:15:28] <SWPadnos_> I don't think we need to worry much about sysfs
[05:15:59] <SWPadnos_> it looks like it's a place to put device nodes that a driver creates - like a cdrom driver making a node when there's a CD in the drive
[05:16:08] <SWPadnos_> (or usb / flash card, etc)
[05:16:18] <SWPadnos_> it's meant for plug-n-play type stuff
[05:16:21] <jmkasunich> ok
[05:16:33] <jmkasunich> it augments, not replaces /dev?
[05:16:40] <SWPadnos_> or udev ;)
[05:16:58] <SWPadnos_> it's a list of devices that are physically present, not all possible devices
[05:17:06] <SWPadnos_> same as udev, I think
[05:17:45] <SWPadnos_> note that there is a Linux comopnent called HAL, so there may be some namespace clashes at some point
[05:17:57] <jmkasunich> enter BLOCS ;-)
[05:18:01] <SWPadnos_> heh
[05:18:17] <jmkasunich> HAL is definitely an overloaded name
[05:18:24] <jmkasunich> RTAI also has a HAL layer
[05:18:25] <SWPadnos_> yep
[05:18:49] <SWPadnos_> everyone does abstraction of the underlying hardware
[05:19:00] <SWPadnos_> (even microsoft does that now)
[05:19:30] <jmkasunich> the linux device driver book talks about some of this stuff
[05:20:14] <jmkasunich> interesting
[05:20:29] <jmkasunich> on my box, with realtime loaded,
[05:20:41] <jmkasunich> /dev contains an entry /dev/rtai_shm
[05:20:54] <SWPadnos_> yes
[05:20:59] <jmkasunich> /proc/devices shows 150 rtai_fifo
[05:21:08] <SWPadnos_> and /proc/emc, I think
[05:21:19] <jmkasunich> the fifo one doesn't appear in /dev, and the shm one doesn't appear in /proc
[05:22:01] <jmkasunich> the book talks about dynamic assighment of major numbers (more portable, less risk of collision)
[05:22:14] <jmkasunich> the driver allocates a chrdev region
[05:22:47] <SWPadnos_> yes - there are also device numbers reserved for "local use" I think
[05:23:03] <jmkasunich> sorry, phone again (but short)
[05:23:03] <jmkasunich> ok
[05:23:10] <jmkasunich> once the driver does the alloc
[05:23:24] <jmkasunich> /proc/devices contains the major number and driver name
[05:23:46] <jmkasunich> then a script can read /proc/devices and do the mknod
[05:24:23] <SWPadnos_> the realtime script creates the device node
[05:24:30] <jmkasunich> in our case, the realtime start script would do ti
[05:24:33] <jmkasunich> heh
[05:24:38] <cradek> jmkasunich: this is interesting
[05:24:45] <cradek> jmkasunich: I have this troubled machine like I explained
[05:24:59] <cradek> jmkasunich: in emc1, at the first glitch, I do get the controller missed realtime deadline error
[05:25:38] <jmkasunich> ok, so the actual glitch is machine specific, not emc2 specific, but emc2's detection is flawed (as in not there)
[05:25:47] <cradek> I think that's right
[05:25:58] <jmkasunich> I think thats good news
[05:26:05] <jmkasunich> (for me anyway ;-)
[05:26:12] <cradek> yeah, I'm not so sure from here
[05:26:18] <jmkasunich> need to look into detection of missed deadlines
[05:26:28] <cradek> but yeah, it means there must be a way to do the detection
[05:26:31] <jmkasunich> on your side, is the MB using shared memory for video?
[05:26:42] <jmkasunich> that is notorious for messing up latency
[05:26:43] <cradek> no, but I am about to try a different video card anyway.
[05:26:56] <SWPadnos_> SCSI drivers loaded?
[05:27:09] <cradek> yes, there is scsi everywhere
[05:27:11] <SWPadnos_> (I hear that's another problem)
[05:27:21] <cradek> hmm
[05:27:25] <SWPadnos_> but should only be if you're using the devices
[05:27:35] <SWPadnos_> unless bus timeouts or the like are happening
[05:27:37] <jmkasunich> can you file a bug report saying "emc1 reports when a realtime deadline is missed, emc2 doesn't" and set the catagory to RTAPI?
[05:27:45] <cradek> jmkasunich: yes
[05:31:02] <jmkasunich> SWPadnos: making the main hal module work like a real driver is probably the right thing to do
[05:31:07] <jmkasunich> non-trivial, but right
[05:31:08] <SWPadnos_> hey - /proc/$PID/exe is a pointer to the full path of the executable
[05:31:31] <SWPadnos_> that could make config file stuff easier if used ;)
[05:31:51] <jmkasunich> I htink there is even a shortcut to the path of "this" executable
[05:31:57] <jmkasunich> just trying to remember it
[05:31:59] <SWPadnos_> yep
[05:32:32] <SWPadnos_> /proc/self
[05:34:46] <SWPadnos_> that's helpful - there's a lot of good info there (command line, cwd, executable path, environment, mmaps, etc)
[05:35:15] <jmkasunich> on my box, cat /proc/self/exe doesn't give the path, it gives the actual binary code
[05:35:27] <SWPadnos_> yes - it's a link to the exe
[05:35:33] <jmkasunich> symlink
[05:35:36] <SWPadnos_> yep
[05:36:37] <jmkasunich> so `readlink /proc/self/exe` gives you the path
[05:36:52] <jmkasunich> nope, that gives you the path to readlink
[05:36:54] <jmkasunich> heh
[05:37:36] <SWPadnos_> I'm looking for the right ls option ;)
[05:40:21] <jmkasunich> well, I'm gonna go back to coding vcp stuff
[05:40:27] <chinamill> * chinamill is back
[05:40:45] <SWPadnos_> ok - I'll look into RT and think about bundles
[05:40:51] <SWPadnos_> RT <-> user, that is
[05:40:55] <jmkasunich> yeah
[05:41:40] <SWPadnos_> hah - I think -L is it
[05:41:50] <jmkasunich> I think that is the key to the hal refactor, which in turn is the key to things like megablocks, and being able to do halcmd save and get everything including the loadrt, and severa other nice things
[05:44:53] <chinamill> Hmm; why should SPINDLE_ON_INDEX be stated as analog output in emc.ini (emc2)? Have anyone had success using it with a 2:nd parport?
[05:46:45] <jmkasunich> in emc2? those index things aren't used at all in emc2
[05:47:08] <jmkasunich> in emc2 you can send any signal out any pin, so 2nd parport is no problem
[05:47:16] <SWPadnos_> the SPINDLE_ON output is in the analog section because it's the analog output number that's used to control the spindle
[05:47:18] <chinamill> ok, time to clean up the ini file then...
[05:47:18] <SWPadnos_> for emc1
[05:47:23] <jmkasunich> but you you HAL to do it, not those index things
[05:47:54] <jmkasunich> chinamill: yes, it needs cleaned up
[05:47:55] <SWPadnos_> is anything in the [IO] section used in emc2?
[05:48:07] <SWPadnos_> other than CYCLE_TIME
[05:48:10] <jmkasunich> I don't think so
[05:48:24] <cradek> yay, a video card change fixed it
[05:48:31] <SWPadnos_> kewl!
[05:48:44] <cradek> but wow do I need a newer video card
[05:48:45] <SWPadnos_> out of curiosity, what was the old one?
[05:49:36] <cradek> BoardName "S3 Savage4"
[05:49:42] <cradek> 8MB
[05:49:48] <SWPadnos_> heh - that's a bit old
[05:50:00] <cradek> ha, that's new compared to my Matrox Millenuim II
[05:50:08] <cradek> the only PCI card I could find in the house
[05:50:14] <SWPadnos_> I'd take the Millennium any day (I still have one ;) )
[05:50:15] <jmkasunich> I've used Matrox cards of that vintage or older with no RT problems
[05:50:23] <cradek> yeah, the matrox is great
[05:50:26] <cradek> it's just slow for AXIS
[05:50:35] <jmkasunich> all of my boxes except the current one have Matrox
[05:50:54] <jmkasunich> (the current one has a 128MH Gforce (nvidia)
[05:50:55] <SWPadnos_> grab a G400, G450, or G550 on ebay, and you'll actually have 3D performance almost 10% as fast as today's cards ;)
[05:50:58] <cradek> matrox has the best vga framebuffer support
[05:51:16] <cradek> SWPadnos_: that's what I was using in the old machine, and it was great
[05:51:19] <cradek> unfortunately it's agp
[05:51:24] <SWPadnos_> yes - the 2D has always been the best, and the video quality
[05:51:30] <SWPadnos_> ah
[05:51:46] <jmkasunich> cradek: your MB has no AGP slot?
[05:51:52] <SWPadnos_> it's too bad they (Matrox) dropped the ball on the Parhelia line
[05:51:54] <cradek> jmkasunich: not the "new" one
[05:51:59] <jmkasunich> gawd, I thought I ran old hardware
[05:52:11] <cradek> it does have 64 bit PCI, which I've never seen before
[05:52:23] <cradek> it's old "server-class" hardware
[05:52:42] <SWPadnos_> like my server - dual-processor Pentium-Pro (with Overdrive CPUs @ 333 MHz)
[05:53:14] <SWPadnos_> though I do have the highly advanced Intel I960 I/O Processotr on board
[06:02:14] <cradek> jmkasunich: I did what you suggested but am still getting spurious joint following errors
[06:03:13] <jmkasunich> with 5% margin?
[06:03:18] <cradek> yes
[06:03:46] <jmkasunich> ok, try setting the stepgen limit to double the traj limit, to completely eliminate that possibility
[06:04:16] <jmkasunich> if it still happens, the something somewhere else is screwing up
[06:04:25] <cradek> working on it...
[06:05:57] <chinamill> Would there be any documentation on addiing a second parport? Or if any one got a hal file with 2 that I can look at?
[06:06:03] <cradek> still the error
[06:06:12] <cradek> I can get it by turning feed override to 120%
[06:06:21] <jmkasunich> but not at 100%?
[06:06:34] <cradek> let me try
[06:06:41] <cradek> certainly not as often
[06:06:58] <jmkasunich> chinamill: I can probably help, but one thing at a time
[06:07:26] <jmkasunich> chinamill: what ini file are you using?
[06:07:38] <cradek> feed override overrides the programmed feed, not the ini max, right?
[06:07:45] <jmkasunich> right
[06:07:46] <alex_joni> hello guys
[06:07:51] <cradek> hello
[06:07:53] <chinamill> jmkasunich: emc.ini
[06:07:57] <chinamill> Hello
[06:08:14] <alex_joni> chinamill: heard you reported some success running emc2
[06:08:27] <jmkasunich> straight out of cvs? what if anything in there did you change?
[06:08:30] <chinamill> great isnt it!
[06:09:20] <cradek> jmkasunich: it's still running but so far hasn't given the error at 100%
[06:09:25] <chinamill> jmkasunich: Some small things.. like adding a 4th axis and limits etc.
[06:09:50] <chinamill> (sorry i'm getting confused)
[06:09:58] <jmkasunich> in the HAL section, you still have core_stepper.hal and standard_pinout.hal?
[06:10:09] <chinamill> jmkasunich: yes
[06:10:14] <jmkasunich> confused by what?
[06:11:11] <chinamill> jmkasunich: I was not sure You where adressing me... But I thougt I must ad the second parport in *.hal file
[06:11:27] <jmkasunich> yes
[06:11:47] <jmkasunich> currently "standard_pinout.hal" loads the parport driver and connects things to it
[06:11:59] <jmkasunich> you must have edited that to hook up the second axis, right?
[06:12:05] <jmkasunich> sorry, fourth axis
[06:12:25] <chinamill> so can I ad something like loadrt hal_parport cfg="[myparpot]"
[06:12:39] <jmkasunich> you can't add it, you can only load the driver once
[06:13:03] <jmkasunich> but the line near the top of the file: loadrt hal_parport cfg="0x0378"
[06:13:04] <chinamill> yes it works, but now I want to add a second parport
[06:13:08] <jmkasunich> can be changed to:
[06:13:18] <alex_joni> you need to change cfg="0x378 0x278"
[06:13:26] <jmkasunich> loadrt hal_parport cfg="0x0378 0x0278"
[06:13:26] <chinamill> aha
[06:13:39] <jmkasunich> or whatever the address of your second parport is
[06:13:54] <chinamill> then I use parport.0.X ?
[06:14:00] <chinamill> then I use parport.1.X ?
[06:14:04] <alex_joni> right
[06:14:07] <jmkasunich> parport.1.xxxxx for the second port
[06:14:26] <chinamill> Great I'll try tomorrow
[06:14:32] <jmkasunich> oh, almost forgot...'
[06:14:38] <jmkasunich> you also need to do addf lines
[06:14:50] <jmkasunich> right below the loadrt line, there are two addf lines
[06:14:59] <chinamill> yes...
[06:15:00] <jmkasunich> addf parport.0.read base-thread 1
[06:15:00] <jmkasunich> addf parport.0.write base-thread -1
[06:15:05] <jmkasunich> add two more:
[06:15:17] <jmkasunich> addf parport.1.read base-thread 1
[06:15:27] <jmkasunich> addf parport.1.write base-thread -1
[06:15:35] <chinamill> ok.. thanks for the direction!
[06:15:53] <jmkasunich> (do you need to send step pulses out of that port, or just generic I/O like spindle and stuff?)
[06:15:57] <alex_joni> jmkasunich: got a pci-board with 2 aditional parports
[06:16:11] <chinamill> ony IO stuff
[06:16:26] <jmkasunich> if you don't need high speed output (steps) then change base-thread in the 2 new lines to servo-thread
[06:16:43] <chinamill> ok
[06:16:44] <jmkasunich> that will reduce CPU loading, it will update the port 1000 times per second instead of 20000 or more
[06:16:58] <chinamill> good idea!
[06:17:15] <jmkasunich> just remember to keep all your step pulses on the fast port
[06:17:25] <chinamill> yep...
[06:19:29] <jmkasunich> I wish all problems were so easy ;-)
[06:19:43] <jmkasunich> I wonder if I can hide before cradek notices?
[06:19:47] <cradek> jmkasunich: it is definitely related to feed override
[06:19:49] <cradek> haha
[06:19:50] <cradek> too late
[06:19:52] <jmkasunich> damn!
[06:20:08] <cradek> at 100% it can cut all of Chips
[06:20:08] <alex_joni> you can't escape a person ;)
[06:20:36] <alex_joni> if you go higher you get problems?
[06:20:47] <jmkasunich> alex: /part works pretty well to escape
[06:20:50] <cradek> at 120 it errors almost right away
[06:21:21] <alex_joni> cradek: did you try to increase the max-speed of stepgen?
[06:21:28] <jmkasunich> any particular axis? any particular spot in chips?
[06:21:29] <cradek> max-accel yes
[06:21:41] <jmkasunich> good point alex
[06:21:41] <alex_joni> disclaimer: still under fever, so I might talk rubbish
[06:21:52] <cradek> jmkasunich: always joint 2 (lower accel and maxvel than the others) and no particular place in Chips
[06:22:13] <alex_joni> I kinda had problems with Z sometimes too (with chips.ngc that is)
[06:22:21] <jmkasunich> raise max-vel the same way you raised max-accel, a few percent first, then if no effect, double it
[06:22:24] <alex_joni> without any aditional machine connected to it..
[06:22:53] <alex_joni> stepgen.x.max-vel ?
[06:22:59] <jmkasunich> something like that
[06:23:09] <jmkasunich> the exact name will be in the .hal file
[06:23:16] <jmkasunich> might be max-velocity
[06:23:20] <alex_joni> stepgen.[0-2].max-vel :D
[06:23:28] <alex_joni> and run through sed
[06:23:40] <alex_joni> or something to expand that
[06:25:15] <cradek> ok, I set the hal values to 105% of ini
[06:25:22] <cradek> FO at 120%
[06:25:58] <cradek> looks promising so far
[06:26:53] <cradek> pretty sure that fixed it
[06:29:23] <alex_joni> * alex_joni had a good idea it seems.. maybe this fever is good afterall
[06:29:54] <jmkasunich> cradek: try changing the max-accel back down to 105%
[06:30:04] <jmkasunich> I bet 105% on both is the solution
[06:31:43] <cradek> back to 105% on both, running at FO 120%
[06:31:51] <cradek> joint 2 following error immediately
[06:32:04] <alex_joni> bummer
[06:32:15] <alex_joni> try increasing it till it doesn't error
[06:32:44] <cradek> just the accel I assume?
[06:33:22] <cradek> trying maxvel 105% maxaccel 110%
[06:33:53] <alex_joni> you could just use bin/halcmd setp stepge.2.max-accel xx
[06:34:06] <alex_joni> when emc is running (hope you're not stopping, rerunning it)
[06:34:07] <jmkasunich> yeah, don't need to edit and restart
[06:34:14] <cradek> ok, I'll try that
[06:34:19] <jmkasunich> just open another shell
[06:34:33] <cradek> still JFE at maxaccel 110%
[06:34:53] <jmkasunich> bin/halcmd setp stepgen.2.maxaccel <number>
[06:35:03] <cradek> it's 20 in the ini
[06:35:09] <cradek> this was 22
[06:35:10] <cradek> I'll try 24, 120%
[06:35:16] <alex_joni> yup
[06:35:42] <jmkasunich> do you have any backlash configured?
[06:35:47] <cradek> no
[06:35:50] <jmkasunich> ok
[06:36:03] <jmkasunich> (same failure mechanism, backlash just makes it worse)
[06:36:31] <cradek> 120% may have fixed it
[06:36:48] <jmkasunich> I'm surprised it needed so much
[06:37:11] <cradek> could this be a FO problem?
[06:37:17] <jmkasunich> dunno
[06:37:32] <alex_joni> what's FO?
[06:37:36] <cradek> feed override
[06:37:38] <jmkasunich> did you make any other changes to the .hal files (except for the max-vel and max-acc tweaks)?
[06:37:39] <cradek> sorry
[06:37:46] <cradek> let me cvsdiff
[06:38:08] <jmkasunich> send me your ini, and if any other changes in the .hal files, send me those too
[06:38:22] <jmkasunich> I'll put halscope on it
[06:38:35] <alex_joni> heh, chris needs to learn that ;)
[06:38:40] <jmkasunich> unless you'd like to learn
[06:38:48] <cradek> I did not change anything of consequence in the hals other than the maxacc/maxvel
[06:38:57] <cradek> sure, if you have time to talk me through it
[06:39:05] <jmkasunich> send the ini, and we can do it in parallel
[06:39:26] <alex_joni> btw.. regarding halscope
[06:39:40] <alex_joni> john: how do you feel about sample configs for it?
[06:39:55] <jmkasunich> good, but...
[06:40:12] <jmkasunich> right now, it always reads the config from .scope.cfg
[06:40:26] <alex_joni> cp should cure that
[06:40:27] <cradek> http://timeguy.com/cradek-files/emc/emc.ini
[06:40:27] <jmkasunich> I need to add a save/restore option
[06:40:59] <jmkasunich> (and I need to finish the actual code that reads the files, right now it doesn't do the triggering part yet)
[06:41:32] <alex_joni> ok.. no rush :)
[06:41:39] <cradek> oh cool, I have halscope built already
[06:41:48] <cradek> I thought I had to do something special last time
[06:41:54] <alex_joni> install gtk
[06:42:03] <cradek> ah
[06:42:12] <jmkasunich> once you have gtk-dev, it builds ok
[06:42:17] <alex_joni> but if you have it, then it should automatically build
[06:42:34] <cradek> jmkasunich: did you see the url of my ini?
[06:42:43] <jmkasunich> yeah, copied to local
[06:42:53] <jmkasunich> I'm dogin a cvs up and make to make sure I'm current
[06:42:58] <jmkasunich> doing
[06:43:18] <cradek> mine is maybe a week old
[06:43:27] <SWPadnos_> cradek - are you running the hardware, or just "simulating"?
[06:43:31] <cradek> running hardware
[06:43:46] <cradek> ooOOOOeeeEEEEEEoooOOOoooooeeeEEE
[06:43:46] <jmkasunich> with steppers, it doesn;t much matter
[06:43:49] <SWPadnos_> but steppers, using stepgen
[06:43:56] <SWPadnos_> yep
[06:43:58] <SWPadnos_> heh
[06:44:12] <cradek> steppers let you easily hear problems
[06:44:15] <SWPadnos_> user sevos - they only hum when they're stopped ;)
[06:44:16] <alex_joni> cradek: got the cat over the keyboard?
[06:44:19] <cradek> I can hear misblends on parallel segments
[06:44:19] <jmkasunich> although I suppose I should unplug the parport cable from the USC card ;-)
[06:44:30] <cradek> alex_joni: no, that's what my mill sounds like
[06:44:51] <alex_joni> * alex_joni runs it through a speechsynthesizer
[06:45:19] <jmkasunich> phttbbbbbt
[06:45:33] <jmkasunich> dammit, you guys gotta get axis into emc2 cvs
[06:45:47] <jmkasunich> every time I do a make clean, it destroys axis
[06:45:56] <jmkasunich> no how do I make axis again?
[06:46:04] <jmkasunich> s/no/now
[06:46:09] <SWPadnos_> cd /path/to/axis
[06:46:28] <SWPadnos_> env EMCROOT=/path/to/emc2 python setup.py install
[06:46:39] <cradek> jmkasunich: you could fix make clean instead
[06:46:46] <SWPadnos_> nah - too easy
[06:46:51] <jmkasunich> cradek: I have 11/20, is that pretty current?
[06:47:00] <cradek> oh hey, I got a joint following error on the last move
[06:47:07] <cradek> jmkasunich: let me look
[06:47:23] <alex_joni> 12/03 is pretty current
[06:47:33] <alex_joni> the rest is old stuff :)
[06:47:48] <alex_joni> kidding :)
[06:48:04] <cradek> there are 10 patchsets since 11/20
[06:48:04] <alex_joni> but they keep advancing with the development..
[06:48:04] <jmkasunich> might as well get the latest
[06:48:39] <cradek> before 11/27 won't even build
[06:48:45] <alex_joni> we had a chat about server load this morning..
[06:48:59] <SWPadnos_> bummer - I missed that
[06:49:06] <alex_joni> if anyone is interested here are some download stats :
http://dsplabs.cs.utt.ro/~juve/emc/.logs/counts/
[06:49:27] <SWPadnos_> does that show download starts, or cpmpleted downloads?
[06:49:36] <SWPadnos_> completed
[06:49:51] <alex_joni> starts..
[06:49:52] <SWPadnos_> ok
[06:49:52] <alex_joni> so might be lower
[06:49:52] <jmkasunich> ok, what do I want to download? from the download page? or the snapshot page?
[06:49:52] <cradek> snapshot page
[06:49:53] <alex_joni> snapshot
[06:49:56] <cradek> bottommost link
[06:50:13] <jmkasunich> or in the first sentence
[06:51:22] <cradek> I just upped my axis too
[06:52:53] <jmkasunich> gotta be root to make axis?
[06:52:58] <cradek> no
[06:53:04] <cradek> to install it you do
[06:53:08] <jmkasunich> error: could not delete '/usr/lib/python2.3/site-packages/rs274/OpenGLTk.py': Permission denied
[06:53:23] <cradek> I guess you're installing
[06:53:29] <cradek> so yes
[06:53:36] <jmkasunich> it won't work without installing, will it?
[06:53:39] <cradek> no
[06:53:43] <jmkasunich> pah
[06:53:47] <cradek> sorry, I wasn't being obtuse on purpose
[06:54:09] <cradek> you can setup.py build, and then setup.py install, I thought you were asking about build
[06:54:30] <jmkasunich> I have so many differnet checkouts on this box, I don't install anything
[06:54:30] <jmkasunich> just run from the directory
[06:54:39] <cradek> same here
[06:54:41] <alex_joni> john: you are installing axis in the emc2 dir
[06:55:01] <jmkasunich> SWP just told me to install (which I guess I needed to do anyway) and that must automatically build
[06:55:08] <alex_joni> yup
[06:55:17] <jmkasunich> alex: I guessed as much (install in emc2 dir)
[06:55:19] <alex_joni> so a sudo infront is not bad habit
[06:55:53] <jmkasunich> ok, built and running
[06:55:58] <cradek> great
[06:56:13] <jmkasunich> open another shell, cd to your emc2 dir
[06:56:34] <jmkasunich> bin/halscope &
[06:57:00] <cradek> I'm with you
[06:57:10] <jmkasunich> the scope window and a dialog should appear
[06:57:16] <cradek> yes
[06:57:26] <jmkasunich> select servo-thread
[06:57:50] <cradek> record length?
[06:57:53] <jmkasunich> leave mult at 1, and rec len at 4047/4 chan
[06:57:57] <cradek> ok
[06:58:13] <jmkasunich> see the row of numbered buttons (1-16)
[06:58:17] <jmkasunich> click on 1
[06:58:29] <jmkasunich> what axis was tripping the most, 2?
[06:58:33] <jmkasunich> aka Z?
[06:58:34] <cradek> yes 2/Z
[06:58:36] <alex_joni> yes
[06:58:57] <jmkasunich> ok, on the signals tab, select Zpos-cmd
[06:59:07] <cradek> ok
[06:59:44] <jmkasunich> click on 2, axis.2.f-error
[07:00:01] <jmkasunich> oops, parameter tab for that one
[07:00:27] <cradek> ok
[07:00:29] <jmkasunich> 3, param tab, axis.2.f-errored
[07:00:49] <cradek> ok
[07:00:52] <jmkasunich> then bottom right corner, "source" (trigger source)
[07:00:59] <jmkasunich> pick channel 3
[07:01:22] <jmkasunich> then near the top, under Run Mode, click normal
[07:01:54] <cradek> ok, it's going
[07:02:02] <jmkasunich> at this point, the scope should trigger on a following error
[07:02:03] <cradek> I'm not getting the FE now
[07:02:10] <jmkasunich> load 3dchips, and start running
[07:02:25] <jmkasunich> I went back to the original max-acc and max-vel
[07:02:43] <jmkasunich> hmm, I got linear move out of range...
[07:02:53] <jmkasunich> I suppose I should home first?
[07:02:56] <cradek> you will have to home and offset properly
[07:03:04] <cradek> Chips is big for my mill
[07:03:10] <cradek> you could open up the limits instead
[07:03:19] <jmkasunich> * jmkasunich doesn't actually use EMC much ;-)
[07:03:35] <cradek> just open up the limits
[07:03:37] <jmkasunich> well we should stay in synch, how are you doing it
[07:04:04] <cradek> ok type X Home Y Home Z Home
[07:04:08] <cradek> you should get the three home icons
[07:04:21] <jmkasunich> little target things?
[07:04:34] <cradek> yes
[07:04:38] <jmkasunich> ok, done
[07:05:06] <cradek> wtf
[07:05:23] <jmkasunich> ?
[07:05:25] <SWPadnos_> wtfw?
[07:05:35] <cradek> I aborted Chips
[07:05:41] <cradek> now MDI doesn't work right
[07:05:46] <cradek> I say g0x0 and it goes somewhere else
[07:05:46] <jmkasunich> you baby killer!
[07:06:53] <SWPadnos_> offset coordinates?
[07:07:06] <SWPadnos_> or - coordinate offsets? ;)
[07:07:07] <cradek> jmkasunich: jog X to +4"
[07:07:19] <cradek> hit shift-home
[07:07:42] <cradek> jog Y to -2.9"
[07:07:42] <cradek> hit shift-home
[07:08:18] <cradek> jog Z to +2.5
[07:08:20] <cradek> hit shift-home
[07:08:22] <jmkasunich> how come no 1.000" incremental jog?
[07:08:42] <cradek> some day we'll make those configurable
[07:08:54] <jmkasunich> ok, all done
[07:08:59] <cradek> now chips should run
[07:09:03] <jmkasunich> whats with the big gray cone
[07:09:08] <cradek> that's where the tool is
[07:09:26] <jmkasunich> the pointer of death... can't see thru it or anything
[07:09:33] <cradek> load chips
[07:09:39] <cradek> the cone scales to an appropriate size
[07:09:45] <jmkasunich> load or reload?
[07:09:47] <SWPadnos_> middle-drag to spin the image
[07:09:55] <cradek> or hit the P icon
[07:10:08] <jmkasunich> I'm in P
[07:10:19] <jmkasunich> its not hiding it right now
[07:10:20] <cradek> do you see chips?
[07:10:24] <cradek> oh, ok
[07:10:53] <jmkasunich> this is nuts
[07:10:58] <cradek> it should run now
[07:11:04] <alex_joni> what is nuts?
[07:11:05] <cradek> I got a ferror right away
[07:11:14] <jmkasunich> when I was doing the jogs and shift-homes, the cone moved as expected, and I could see chips
[07:11:43] <jmkasunich> (I was in P) after changing from P to Z to X to Y to P again
[07:11:54] <jmkasunich> I have a really botched up display
[07:12:07] <jmkasunich> one of the dimensions is 101.60
[07:12:19] <cradek> well ... that's the bug jepler is working on
[07:12:22] <cradek> the problem is
[07:12:24] <jmkasunich> and chips (if thats him) is a tiny blur over near the other end
[07:12:24] <SWPadnos_> heh
[07:12:29] <cradek> Chips is in metric
[07:12:31] <cradek> the ini is in inches
[07:12:36] <SWPadnos_> use the scroll wheel to zoom
[07:12:41] <cradek> the program aborted in the middle of Chips
[07:13:04] <cradek> the moral of the story is axis sent mm offsets to emc, which interpreted them as inch
[07:13:33] <cradek> it was caused by that abort that you got when you tried to exceed limits
[07:13:36] <jmkasunich> the moral of the story is units are still fucked up
[07:13:48] <cradek> yep
[07:13:55] <jmkasunich> should I just start over?
[07:14:10] <SWPadnos_> hmmm - is that why I get weird scaling (like disappearing models) when I zoom out to wide views?
[07:14:11] <cradek> maybe so
[07:14:16] <SWPadnos_> hi Matt
[07:14:23] <cradek> don't run chips until you get offsets set right
[07:14:32] <jmkasunich> halscope will remember most of its setup
[07:14:37] <mshaver> hi!
[07:14:43] <cradek> hello
[07:14:48] <jmkasunich> hi matt
[07:15:17] <jmkasunich> ok, estop off, machine in run, time for offsets
[07:15:28] <cradek> home all 3 axes
[07:15:41] <jmkasunich> is "shift-home" the same as hitting the offset button?
[07:15:44] <cradek> yes
[07:15:45] <mshaver> * mshaver ...is talking to dave engvall on the phone...
[07:15:51] <SWPadnos_> what about?
[07:16:12] <cradek> X=4, offset
[07:16:16] <cradek> Y=-2.8, offset
[07:16:21] <cradek> Z=2.5, offset
[07:16:29] <mshaver> g-code reading from disk
[07:16:44] <SWPadnos_> for really big files?
[07:17:08] <jmkasunich> done, got a nice pic now in P mode
[07:17:18] <cradek> yay
[07:17:30] <jmkasunich> the tool is out beyond Chip's right foot
[07:17:35] <mshaver> all sizes
[07:18:04] <cradek> are the colored axes over top of his middle?
[07:18:10] <cradek> that's the relative origin
[07:18:11] <jmkasunich> scope is armed (I had to select the trigger source again
[07:18:17] <jmkasunich> yes
[07:18:22] <cradek> ok, it should run
[07:18:56] <jmkasunich> it moved to the origin, the said linear move 14 out of range
[07:19:04] <cradek> arrrgh
[07:19:06] <jmkasunich> s/the/then
[07:19:06] <cradek> that's right
[07:19:12] <cradek> someone screwed up the 3D_Chips file
[07:19:18] <cradek> I had to fix mine
[07:19:32] <cradek> comment out lines N21 N22
[07:19:33] <jmkasunich> who screwed with it?
[07:19:39] <cradek> I don't know, but it was recent
[07:20:00] <jmkasunich> if its broken, it should be fixed
[07:20:04] <cradek> I also commented N6921
[07:20:33] <cradek> I'll check it in
[07:20:43] <jmkasunich> hang on first
[07:20:46] <alex_joni> guess who screwed with it?
[07:20:47] <SWPadnos_> it must be recent, because I can run chips just fine here (by just homing each axis)
[07:20:50] <alex_joni> ROFL
[07:20:52] <jmkasunich> ray, right?
[07:21:01] <alex_joni> jmk ;)
[07:21:06] <jmkasunich> ?
[07:21:10] <jmkasunich> in october?
[07:21:15] <cradek> hmm
[07:21:15] <alex_joni> latest revision is by you (6 weeks)
[07:21:23] <cradek> with a log message that makes no sense whatsoever
[07:21:31] <jmkasunich> heh, that was by ray I think
[07:21:38] <jmkasunich> while working on the mazak
[07:21:40] <alex_joni> yeah.. probably commited along with some other stuff
[07:21:47] <jmkasunich> (the checkout on that box is under my name)
[07:21:50] <cradek> ah
[07:21:59] <cradek> I bet it was a mistake
[07:22:03] <jmkasunich> he added a change of coordinate systems to it
[07:22:10] <alex_joni> http://cvs.sourceforge.net/viewcvs.py/emc/emc2/nc_files/3D_Chips.ngc?r1=1.3&r2=1.4
[07:22:17] <jmkasunich> for the mazak, Z = 0 is with quill fully retracted
[07:22:30] <jmkasunich> for chips, z=0 is much lower
[07:22:31] <alex_joni> Lines N21, N22, N6932
[07:22:43] <cradek> everyone else uses G54 for work offsets
[07:22:51] <cradek> I think it's bad to clear them in the program!
[07:23:11] <SWPadnos_> r1.4 runs fine, but I don't do shift-home, just home
[07:23:25] <cradek> SWPadnos_: you don't use limits then
[07:23:35] <SWPadnos_> I don't use a machine ;)
[07:23:38] <cradek> ha
[07:23:46] <cradek> limits are nice to have with a machine
[07:24:00] <cradek> jmkasunich: just edit the file (or get r1.3) and hit reload in axis
[07:24:03] <SWPadnos_> I'm sure
[07:24:14] <jmkasunich> does anybdy know where that limit is actually being hit? I suspect in the interp
[07:24:44] <jmkasunich> there are limits enforced in the motion code, but the motion code never uses fscked up units
[07:25:02] <cradek> jmkasunich: it's not a matter of that, it's sending the MDI to set the offset
[07:25:08] <cradek> g10 l2 p1 x9
[07:25:12] <cradek> could mean 9" or 9mm
[07:25:16] <jmkasunich> all its commands arrive in machine units (the units used in the ini file for vel, accel, limits, etc)
[07:25:17] <cradek> big difference
[07:26:16] <SWPadnos_> does G20/G21 affect that, or is it always in the "base" unit?
[07:26:28] <jmkasunich> heh, the motion controller doesn't know beans about offsets either
[07:26:47] <jmkasunich> the motion controller always uses ini file units, and always uses absolute coords
[07:26:51] <cradek> SWPadnos_: I haven't studied this yet, I just noticed the bug today, doing exactly what jmk did
[07:26:54] <jmkasunich> it enforces soft limits
[07:27:08] <jmkasunich> damned if I know why the interp is even worrying about limits
[07:27:09] <SWPadnos_> ok - the interp should be doing the work there
[07:27:51] <cradek> anyway, back at the ranch
[07:27:52] <jmkasunich> cradek: a thought for an axis feature: plot the machines work envelope
[07:27:59] <cradek> I have two red lines and one green
[07:28:03] <cradek> the green one has a spike in it
[07:28:14] <jmkasunich> mine never triggered
[07:28:21] <jmkasunich> ok,
[07:28:23] <cradek> did you set FO to 120%?
[07:28:28] <jmkasunich> the green one is the currently selected channel
[07:28:47] <jmkasunich> no, I got that fscking damned limit error, and haven't edited the g-code yet
[07:29:16] <jmkasunich> I'll do that in a sec
[07:29:30] <jmkasunich> in the meantime, you can select any channel, just click on the nunbered button
[07:29:41] <jmkasunich> it will go green, and the number and source will be displayed below
[07:29:59] <jmkasunich> the "Vertical" controls to the right work on the selected channel
[07:30:09] <jmkasunich> * jmkasunich edits
[07:31:07] <cradek> oooh
[07:31:08] <cradek> cool
[07:31:24] <alex_joni> what's cool?
[07:31:27] <alex_joni> halscope?
[07:31:27] <cradek> halscope
[07:31:32] <alex_joni> yeah ;)
[07:31:44] <cradek> I get a nice linear increase in ferror until it trips
[07:32:29] <cradek> I agree it would be really neat to somehow show the absolute work envelope
[07:32:51] <cradek> I'm not sure how to do it though... I could definitely draw a box out of lines
[07:32:54] <jmkasunich> you said to comment out N21, N22, and N6921?
[07:33:09] <jmkasunich> looks like the G54 is on N6932
[07:33:14] <alex_joni> I'd say 6932
[07:33:23] <cradek> yes
[07:33:29] <cradek> sure, 6932 also
[07:33:48] <cradek> it's harmless though, since the rel origin is in the envelope
[07:33:57] <SWPadnos_> did you have to comment out N50 and N60?
[07:34:09] <jmkasunich> fscker...
[07:34:15] <jmkasunich> move out of range again
[07:34:17] <cradek> nope
[07:34:21] <SWPadnos_> hmmm
[07:34:27] <cradek> jmkasunich: edit the ini and open the limits
[07:34:35] <cradek> jmkasunich: it won't affect this error
[07:34:41] <jmkasunich> sounds like a plan
[07:34:54] <cradek> jmkasunich: if you can't see the table on the mill when you're setting offsets, it probably sucks
[07:35:23] <cradek> chips is 4" wide and my Y travel is barely more than that
[07:35:31] <SWPadnos_> weird - I get no motion unless those are commented out - I think I need to connect some more motion pins
[07:35:51] <jmkasunich> heh, big assed machine now - I added 100 in front of your numbers
[07:35:58] <cradek> perfect
[07:36:05] <cradek> home wherever you damn well please
[07:36:15] <SWPadnos_> that's my solituin ;)
[07:36:19] <SWPadnos_> solution
[07:37:05] <jmkasunich> ok, machining happily at FO = 100
[07:37:28] <jmkasunich> went to 120, got an error
[07:38:04] <jmkasunich> damn, nearly 0.050 error when it tripped
[07:38:09] <cradek> SWPadnos_: I hope Z with the tool near the table and have the limits 0-maxheight, so if the program has a bug that will drill into the table, emc stops and tells me
[07:38:31] <cradek> jmkasunich: yeah, I get a linear increase in ferror during a jog...?
[07:38:38] <SWPadnos_> I'm sure I'll do something like that when I actually connect hardware
[07:38:39] <cradek> I wonder if my PERIOD is too big now
[07:38:50] <SWPadnos_> though I'll have limit switches everywhere as well
[07:39:16] <cradek> SWPadnos_: even home switches would be nice here, but I make do
[07:39:19] <SWPadnos_> so - I managed to get a following error at FO=300%, using the PPMC
[07:39:39] <jmkasunich> the commanded Z pos was changing at 3.5 divs * 0.200/div in 4 divs at 500mS/div
[07:39:41] <SWPadnos_> yeah - on a Bridgeport, I think the switches are a little more important :)
[07:39:56] <jmkasunich> that is 0.7" in 2 secs, or 0.35 ips
[07:40:24] <cradek> 21 ipm
[07:40:54] <jmkasunich> max vel in the ini file is 0.3334 ips
[07:41:04] <cradek> yeah, interesting isn't it
[07:41:11] <cradek> I just noticed that too
[07:41:14] <jmkasunich> so the TP was asking for too much
[07:41:56] <jmkasunich> and nice stepgen module refused to allow it
[07:42:45] <jmkasunich> 8000 steps/inch, so you are talking about less than 3000 HZ here, its not a period issue
[07:43:00] <SWPadnos_> it's not using the axis max_vel - it's using the TRAJ value (I think)
[07:43:22] <jmkasunich> I bet your right
[07:43:28] <SWPadnos_> axis_0 and AXIS_1 are set the same as TRAJ
[07:43:58] <jmkasunich> [TRAJ]MAX_VEL should be set to the lowest axis value
[07:44:09] <SWPadnos_> I don't think so
[07:44:11] <jmkasunich> or maybe a hair lower to avoid headroom issues
[07:44:11] <cradek> lowest??
[07:44:17] <cradek> surely not
[07:44:20] <SWPadnos_> it should be the max allowed by the machine
[07:44:37] <jmkasunich> yes, TRAJ limit is the speed that the TP will attempt to move the tooltip in any direction
[07:44:51] <alex_joni> even Z's
[07:44:54] <cradek> but if I'm moving in X, I want it to go faster than that
[07:44:55] <SWPadnos_> that should be limited by the axis value, if it's lower
[07:45:03] <cradek> right
[07:45:20] <cradek> otherwise there's no point to having some axes set faster
[07:45:32] <jmkasunich> well that intelligence, if any, is in code that I've never worked on, so I assume it is broken ;-)
[07:45:41] <SWPadnos_> you can do a compound move that's faster than any axis, actually - sqrt(#axes)*max
[07:46:11] <cradek> that's also true
[07:46:29] <cradek> the axis maxvel is a projection of the move onto the axis
[07:46:58] <cradek> (or something like that)
[07:47:00] <cradek> * cradek waves his hands
[07:47:06] <SWPadnos_> and it was so
[07:47:11] <jmkasunich> so the TP needs to do the projection(s), then figure out if any axis limit will be exceeded, and if so "refuse" to follow the commanded feedrate?
[07:47:17] <cradek> yes
[07:47:18] <SWPadnos_> yep
[07:47:33] <jmkasunich> well I have no idea if the existing TP does that
[07:47:43] <jmkasunich> it seems non trivial is you have kins
[07:47:46] <cradek> this has always worked in emc1
[07:47:46] <alex_joni> let me guess.. it doesn't ;)
[07:47:56] <cradek> I've always had axes set differently
[07:48:01] <cradek> even X and Y were different for a while
[07:48:09] <jmkasunich> multiple passes thru the kins to to the projection, instead of just one with the final position
[07:48:19] <jmkasunich> s/to to/to do
[07:49:24] <jmkasunich> chips just sets the feed in one place, right?
[07:49:44] <cradek> I'm not sure
[07:49:57] <SWPadnos_> no - you do one pass, then scale all axes by the lowest ratio of AXIS_max:Requested_max
[07:50:29] <alex_joni> SWPadnos: TP should do adaptive control
[07:50:31] <jmkasunich> 3 places
[07:50:44] <jmkasunich> twice to 225, once to 450
[07:50:47] <alex_joni> as you go, when one of them is too fast, it needs to slow down
[07:50:53] <SWPadnos_> yes
[07:50:55] <cradek> see emccanon.cc ~ line 264
[07:51:12] <jmkasunich> I want to increase the Fs in the file by 120%, then set feedrate override to 1.0 and see if the same thing happens
[07:51:28] <jmkasunich> the TP may correctly limits feeds, but not overrides
[07:51:39] <cradek> that could sure be
[07:51:46] <SWPadnos_> alex_joni: on a per-segment basis, look at the requested velocities, then scale to the lowest common denominator
[07:52:00] <alex_joni> ahh.. ok ;)
[07:52:06] <alex_joni> thought a whole program
[07:52:18] <SWPadnos_> nope ;)
[07:53:19] <jmkasunich> ok, running again, with F270 and F540 instead of F225 and F450
[07:53:42] <jmkasunich> got past the spot that tripped it before
[07:54:17] <jmkasunich> I bet the TP is oblivious to "scale" aka feedrate override
[07:54:55] <cradek> starving ... must ... go ... eat
[07:55:24] <cradek> I'll be back later
[07:55:31] <cradek> jmkasunich: I think you've figured it out
[07:55:47] <cradek> jmkasunich: I'll try to help you find the fix...
[07:56:17] <jmkasunich> heh, 450mm/min = 0.295 ips * 1.2 = 0.354 ips
[07:56:35] <jmkasunich> which is where we were tripping
[07:57:03] <SWPadnos_> I winder if all those empty {ENABLE_,DISABLE_)(FEED,SPEED}_OVERRIDE functions have something to do with it? ;)
[07:57:06] <SWPadnos_> wonder
[07:57:09] <jmkasunich> but when the g-code says 540mm/min (which is also 0.354 ips) we don't trip, the TP must slow it down
[07:57:29] <jmkasunich> SWP: I'm almost certain they don't
[07:57:38] <alex_joni> probably the feedoverride gets applied after the speed check
[07:57:39] <SWPadnos_> somewhere near line 1014 of emccanon.cc
[07:57:55] <jmkasunich> they refer to disabling the buttons so an operator can't crank feedrate beyond what the g-code programmer wanted
[07:58:04] <SWPadnos_> ah - ok
[07:58:20] <jmkasunich> feedrate override gets applied down in the RT motion control
[07:58:37] <jmkasunich> there is a variable called "scale", normally 1.0, that gets changed by override
[07:58:48] <jmkasunich> it is applied to the TP, but I don't know where or how
[07:59:23] <jmkasunich> chips is half done, using the stock .hal file that sets stepgen limits exactly the same as ini limits
[07:59:33] <jmkasunich> this is strictly related to feed override
[08:00:06] <jmkasunich> cradek had just the right limits
[08:00:20] <jmkasunich> high enough to run it at the standard speed
[08:00:28] <jmkasunich> low enought to fail at override speed
[08:00:59] <SWPadnos_> this stuff should be in emc/motion/control.c, right?
[08:01:09] <jmkasunich> indirectly
[08:01:13] <SWPadnos_> heh
[08:01:16] <jmkasunich> control.c calls the actual TP code
[08:01:24] <jmkasunich> tp.c, tc.c, and maybe others
[08:01:54] <jmkasunich> I basically rewrote control.c from scratch, but the others are virtually untouched
[08:02:20] <jmkasunich> I'm gonna try another test
[08:02:21] <alex_joni> emcmotStatus->qVscale = emcmotCommand->scale;
[08:02:21] <alex_joni> tpSetVscale(&emcmotDebug->queue, emcmotCommand->scale);
[08:02:29] <jmkasunich> set Z radicaly slower than X and Y
[08:02:39] <jmkasunich> set the g-code F command real high
[08:02:51] <jmkasunich> and watch to see if the TP slows down the vertical moves
[08:04:05] <SWPadnos_> set the max override to 3x or something - make it easy on yourself
[08:05:36] <jmkasunich> ok, max FO = 2, X, Y max v = 0.5, Z maxv = 0.05, F10000 in the program
[08:05:36] <alex_joni> jmk: can you try something first?
[08:05:45] <alex_joni> although probably it won't matter much..
[08:05:55] <alex_joni> try setting the feed override while paused
[08:06:30] <jmkasunich> started with override = 100%
[08:06:49] <jmkasunich> and it is respecting the axis limits, horizontal moves are much faster than vertical
[08:07:28] <alex_joni> I think the problem is in tc.c
[08:07:39] <jmkasunich> I'm inclined to agree with you
[08:07:41] <alex_joni> if (newVel > (tc->vMax - tc->preVMax) * tc->vScale) {
[08:07:42] <alex_joni> newVel = (tc->vMax - tc->preVMax) * tc->vScale;
[08:07:42] <alex_joni> isScaleDecel = 1;
[08:07:42] <alex_joni> }
[08:07:42] <alex_joni> /* clamp scaled velocity against absolute limit */
[08:07:42] <alex_joni> if (newVel > tc->vLimit) {
[08:07:43] <alex_joni> newVel = tc->vLimit;
[08:07:45] <alex_joni> }
[08:07:49] <alex_joni> the later if is the problem
[08:08:02] <alex_joni> it only checks (clamps) on absolute limit
[08:09:20] <jmkasunich> heh, its fun to watch with the axis limits so asymmetric
[08:09:22] <SWPadnos_> I think that limit was supposed to be the min of all axis limits (set in the *ini.cc files)
[08:09:42] <jmkasunich> it just zooms thru the horizontal (or nearly so) parts, then crawls up and down the more vertical ones
[08:10:11] <jmkasunich> so it is applying individual axis limits
[08:10:46] <SWPadnos_> actually - it's the earlier if that's the problwm
[08:10:48] <alex_joni> case EMCMOT_SET_VEL_LIMIT:
[08:10:49] <alex_joni> rtapi_print_msg(RTAPI_MSG_DBG, "SET_VEL_LIMIT");
[08:10:49] <alex_joni> emcmot_config_change();
[08:10:49] <alex_joni> /* set the absolute max velocity for all subsequent moves */
[08:10:49] <alex_joni> /* can do it at any time */
[08:10:49] <alex_joni> emcmotConfig->limitVel = emcmotCommand->vel;
[08:10:50] <alex_joni> tpSetVlimit(&emcmotDebug->queue, emcmotConfig->limitVel);
[08:10:57] <SWPadnos_> if vel > max * scale, then make it max * scale
[08:11:02] <alex_joni> that's the Vlimit we were talking about
[08:11:17] <SWPadnos_> ok
[08:11:31] <alex_joni> looking now what is gets set to
[08:12:12] <alex_joni> trajInifile->find("MAX_VELOCITY", "TRAJ")
[08:12:15] <alex_joni> I rest my case ;)
[08:12:22] <SWPadnos_> jmkasunich: what happens on coordinated moves? (really slow axis + fast axis)
[08:12:37] <jmkasunich> seems to be limited to match the slow axis
[08:12:41] <alex_joni> it goes as slow as to allow the slow axis to be able to move
[08:12:44] <SWPadnos_> well - it's *supposed* to be the min for all aexs ;)
[08:12:48] <jmkasunich> a horizontal move is fast
[08:12:53] <jmkasunich> vertical is slow
[08:13:04] <jmkasunich> angled is inbetween, depending on the steepness of the angle
[08:13:17] <jmkasunich> you know, this really needs a test program instead of chipps
[08:13:39] <alex_joni> * alex_joni goes to bed
[08:13:43] <jmkasunich> night alex
[08:13:45] <alex_joni> nice stuff though
[08:13:49] <SWPadnos_> night
[08:13:51] <alex_joni> too bad I can't stay ;)
[08:14:04] <SWPadnos_> cool - you should be able to MDI a move like G1X100Z1, and have it go full rate (assuming that the ratio is <100:1)
[08:14:07] <alex_joni> night all.. I'll read the logs tomorrow
[08:16:02] <jmkasunich> hmm, a circle in the xz plane should demonstrate it too
[08:16:09] <SWPadnos_> yep
[08:16:17] <SWPadnos_> I wonder if accel is also being multiplied
[08:16:31] <SWPadnos_> I got an error using 3X FO, using USC hardware
[08:16:34] <jmkasunich> I suspect so,
[08:16:52] <SWPadnos_> the USC is quite capable of keeping up with ahything I throw at it
[08:17:03] <jmkasunich> with usc hardware the PID tuning comes into the picture
[08:17:06] <SWPadnos_> (max_vel set to 180 IPM@40Ksteps/inch)
[08:17:07] <jmkasunich> muddies things up
[08:17:10] <SWPadnos_> true
[08:17:42] <jmkasunich> I thought there was a test .ngc program with circles in all three planes
[08:17:42] <SWPadnos_> I could increase PGain from 100 to 500 or so, and see what happens
[08:17:56] <jmkasunich> that way lies madness
[08:18:03] <SWPadnos_> circletest.ngc?
[08:18:10] <jmkasunich> you want to isolate issues, not combine them
[08:18:17] <SWPadnos_> yes
[08:18:19] <jmkasunich> I don't see that one
[08:18:31] <SWPadnos_> check one of your other checkouts ;)
[08:19:05] <jmkasunich> 3dtest, part of emc1
[08:19:15] <jmkasunich> should probably copy that over to 2 and commit
[08:19:16] <jmkasunich> later
[08:19:47] <SWPadnos_> right - circletest is what I named Ken Lerman's test circle file, that uses his looping stuff
[08:20:22] <jmkasunich> something looks screwy in 3dtest
[08:20:39] <jmkasunich> the XY circle and the text labeling it are at differnt Z levels
[08:20:57] <jmkasunich> the circle is a couple inches below where it should be
[08:21:09] <jmkasunich> (below the origin)
[08:21:30] <SWPadnos_> it doesn't look that way to me
[08:21:41] <jmkasunich> the text is on the XY plane where it belongs, the circle a couple inches lower
[08:22:16] <SWPadnos_> click the X view button
[08:22:38] <SWPadnos_> it's flat for me
[08:22:42] <jmkasunich> its still there
[08:22:48] <SWPadnos_> is it red or white?
[08:23:08] <jmkasunich> red now, cause its been macined
[08:23:14] <jmkasunich> machined
[08:23:25] <jmkasunich> the tool is following the white path, both are wrong
[08:23:26] <SWPadnos_> ok - did you click the broom icon after loading?
[08:23:32] <jmkasunich> yes
[08:23:33] <SWPadnos_> ok
[08:23:40] <SWPadnos_> (just doing stupid checks ;) )
[08:24:02] <SWPadnos_> we must have different versions of the file - it looks perfect here
[08:24:05] <jmkasunich> I did abort out of chips before loading this one
[08:24:57] <SWPadnos_> relativ offsets still around"?
[08:25:11] <jmkasunich> it looked like it did the entire XZ circle at the same rate
[08:25:22] <jmkasunich> this time I will carefully check as it does the YZ one
[08:25:30] <SWPadnos_> interesting - I just got a joint 2 following error at 60% feed rate (F30 commanded)
[08:26:44] <jmkasunich> confirmed, circles in YZ are done at a constant rate, it doesn't speed up on the near horiz parts and slow down on the near vert ones
[08:27:08] <jmkasunich> but when it draws the Z, the top and bottom bars are MUCH faster than the angled one
[08:27:15] <SWPadnos_> right - it would computer the max Z vel for the entire circle, and slow down appropriately
[08:27:28] <SWPadnos_> compute
[08:27:40] <SWPadnos_> it looks like it does it on a move by move basis
[08:27:44] <jmkasunich> yes
[08:27:57] <SWPadnos_> hmmm - there may be something else going on here
[08:28:02] <jmkasunich> all this is at FO = 100%
[08:28:17] <SWPadnos_> I just ran the file once perfectly, and the second time, I got a joint 2 following error
[08:28:23] <SWPadnos_> at FO= 60%
[08:28:37] <jmkasunich> too many variables
[08:29:03] <jmkasunich> you don't know whether the motion module is giving the PID an unfollowable path, or the PID is failing to follow a legal path
[08:29:21] <jmkasunich> until you can answer that question with certainty, you don;t know anything
[08:29:29] <SWPadnos_> the PID keeps up fine with 3d_chips at high speeds, or MDI moves (high speed being 180 IPM)
[08:29:50] <SWPadnos_> actually - this file uses G0 moves for the text portions - are those overridden by FO?
[08:29:56] <jmkasunich> I'd be tempted to test with sim.ini
[08:30:01] <jmkasunich> suposed to be
[08:30:13] <jmkasunich> sim.ini has no PID, it feeds command right back
[08:30:18] <jmkasunich> so it will never ferror out
[08:30:20] <SWPadnos_> are you sure - G0 is "max rate, uncoordinated"
[08:30:36] <SWPadnos_> or at least, not required to be coordinated
[08:30:44] <jmkasunich> according to ray, FO changes everything
[08:30:50] <SWPadnos_> ok
[08:30:58] <jmkasunich> anyway, back to sim.ini
[08:31:05] <SWPadnos_> "changes" or "is supposed to change" ? :)
[08:31:30] <jmkasunich> the sim hal file puts (I think) a pair of differentiators on each output signal, so you get velocity and accel signals
[08:31:45] <jmkasunich> scope em, trigger on one or the other exceeding limit
[08:31:58] <SWPadnos_> ok
[08:32:11] <jmkasunich> I'm pretty sure it is now "changes"
[08:32:20] <jmkasunich> IIRC I had to change the jogging code to handle that
[08:32:41] <SWPadnos_> ok. weird - shouldn't jogs be at a programmed rate, not G0?
[08:33:29] <jmkasunich> confirmed, just held down the left arrow to jog X, and dragged the FO slider, the speed changed
[08:33:54] <SWPadnos_> ok
[08:33:56] <jmkasunich> yes, on tkemc they use a rate set by a slider near the left of the screen
[08:34:11] <jmkasunich> I don't see a similar slider for axis
[08:34:21] <SWPadnos_> right
[08:35:01] <jmkasunich> ok,did more jogging
[08:35:13] <jmkasunich> for FO from 0 to 100, the speed changed
[08:35:17] <jmkasunich> for 100 to 200, no change
[08:35:28] <jmkasunich> I suspect its already at the axis limit
[08:36:00] <SWPadnos_> ok
[08:36:50] <jmkasunich> anyway, be aware: jogging in emc2 is handled by completely differnt code
[08:36:55] <jmkasunich> doesn't use the old TP at all
[08:37:08] <SWPadnos_> phone
[08:37:12] <jmkasunich> (also, I wrote that code, so if there are problems with jogging, I need to fix them)
[08:37:21] <SWPadnos_> ok
[08:40:11] <jmkasunich> ok, jogging vel limit is handled at control.c, line 1434
[08:40:29] <jmkasunich> /* velocity limit = planner limit * global scale factor */
[08:40:30] <jmkasunich> /* the global factor is used for feedrate override */
[08:40:30] <jmkasunich> vel_lim = joint->free_vel_lim * emcmotStatus->qVscale;
[08:40:30] <jmkasunich> /* must not be greater than the joint physical limit */
[08:40:30] <jmkasunich> if (vel_lim > joint->vel_limit) {
[08:40:31] <jmkasunich> vel_lim = joint->vel_limit;
[08:40:33] <jmkasunich> }
[08:41:07] <jmkasunich> the second part ensures that high FO factors won't overspeed the axis
[08:44:20] <SWPadnos_> there should be one place where all the vel / accel limits are applied
[08:44:42] <SWPadnos_> or is that the one?
[08:44:44] <jmkasunich> there is - stepgen ;-)
[08:44:52] <jmkasunich> no, that is for free mode only
[08:44:57] <SWPadnos_> ok - where all the request limits are applied ;)
[08:45:03] <jmkasunich> ?
[08:45:36] <SWPadnos_> well - ferror accumulates whtn the TP asks for a vel that stepgen can't provide
[08:45:40] <SWPadnos_> when
[08:45:52] <SWPadnos_> the TP shouldn't be asking for anything faster than the machine limits, ever
[08:45:54] <jmkasunich> the coord mode TP can generate commands, the free mode TP can generate commands, we haven't even talked about teleop mode
[08:46:24] <jmkasunich> exactly "the TP shouldn't be asking for anything faster than the machine limits, ever"
[08:46:36] <jmkasunich> but it does, hence its broken
[08:46:40] <SWPadnos_> right
[08:46:56] <jmkasunich> I can (just did) show you the code that keeps my free mode TP from doing that
[08:47:08] <jmkasunich> I have no idea what code prevents it on the other TP
[08:47:18] <SWPadnos_> ok
[08:47:30] <jmkasunich> and then of course, there is backlash comp, which is added to the output of either TP and can make it exceed limits :-(
[08:48:01] <SWPadnos_> that's where the stepgen / other driver comes in - it should do its own slew rate limiting
[08:48:16] <SWPadnos_> I'm pretty sure that's what the steppermod did in emc1
[08:48:19] <jmkasunich> and it does, resulting in a following error
[08:48:39] <SWPadnos_> not necessarily, if you have some headroom
[08:48:53] <jmkasunich> without backlash, stepgen needs only 1-2% headroom
[08:48:54] <SWPadnos_> and some PID
[08:49:01] <jmkasunich> with backlash it will need more
[08:49:06] <SWPadnos_> yep
[08:49:22] <jmkasunich> if you go from stopped to max vel at max accel in the TP
[08:49:30] <jmkasunich> and the backlash comp added its own to that
[08:49:36] <jmkasunich> you can never catch up
[08:49:47] <jmkasunich> (with zero headroom)
[08:50:00] <jmkasunich> with some headroom, you catch up at a rate depending on the headroom
[08:50:23] <SWPadnos_> you can with headroom - remember that the actual accel limit is higher when you're just compensating for backlash
[08:50:30] <SWPadnos_> right
[08:50:31] <cradek> I'm much better now
[08:50:44] <SWPadnos_> properly fooded
[08:51:23] <SWPadnos_> you know - the ppmc / USC cards have a logical design error
[08:51:32] <jmkasunich> only 1?
[08:51:38] <SWPadnos_> another one ;)
[08:51:56] <SWPadnos_> you don't necessarily want the brake output to shut off when the enable out is off
[08:52:12] <jmkasunich> what brake?
[08:52:25] <SWPadnos_> DOUT3 is brake, by default
[08:52:28] <jmkasunich> axis, or spindle?
[08:52:33] <jmkasunich> spindle I think
[08:52:39] <SWPadnos_> ah - right
[08:52:45] <jmkasunich> you keep changing the subject ;-)
[08:52:56] <SWPadnos_> but nonetheless, you can't have any axis brake controlled by the ppmc/ usc either
[08:53:15] <SWPadnos_> sorry - I just noticed the light going on an d off when I toggled estop in axis
[08:53:29] <jmkasunich> any axis brake should be controlled (directly or indirectly) by axis.[0-2].enable
[08:53:42] <jmkasunich> indirectly means you might use some CL or something
[08:54:18] <SWPadnos_> yes - but it can't go through the ppmc card outputs, since those will be turned off if master enable goes away (or SSR8 is turned off)
[08:54:36] <jmkasunich> for instance, on the mazak, ray inserted a delay, he didn't disable the Z amp until a fraction of a second after the enable turned off, to allow time for the brake to grab
[08:54:46] <jmkasunich> otherwise the axis would drop a bit
[08:54:56] <SWPadnos_> yep
[08:55:13] <jmkasunich> any sane brake arrangment applies the brake when power goes away
[08:55:27] <SWPadnos_> true -they should be negative logic
[08:55:52] <jmkasunich> the spindle brake on a bport isn't like that
[08:56:03] <jmkasunich> and the polarity is set up for that
[08:56:42] <jmkasunich> set up for bport I mean
[08:56:43] <SWPadnos_> ok (I don't have a brake, and I haven't checked the polarity of the VFD brake input)
[08:56:52] <SWPadnos_> if ther eis one
[08:57:05] <jmkasunich> probalby just command zero speed
[08:57:37] <SWPadnos_> yep - it wouldn't be a physical brake, just a momentum dump
[08:58:01] <jmkasunich> now that cradek is back, do we want to dive into this TP thing?
[08:58:27] <SWPadnos_> sure (though I'll probably be leaving for food in around 1.5-2.5 hours ;) )
[08:58:30] <jmkasunich> * jmkasunich really doesn't want to look at the TP code, it gives me heartburn
[08:58:36] <jmkasunich> same here
[08:58:48] <jmkasunich> but we can give it an hour or two
[08:58:54] <SWPadnos_> yep
[08:59:22] <jmkasunich> gentlemen, start your editors
[08:59:27] <cradek> ha
[08:59:28] <jmkasunich> lets start with where it is called
[08:59:41] <jmkasunich> control.c line 1542 and following
[08:59:44] <cradek> the feed override ends up in tc->vScale
[09:00:30] <jmkasunich> tpRunCycle gets called whenever the interplator runs out of data and needs a new point
[09:00:33] <cradek> the bug is tc.c line 417
[09:00:42] <jmkasunich> damn he's good
[09:00:47] <jmkasunich> * jmkasunich opens tp.c
[09:00:50] <jmkasunich> tc.c
[09:00:51] <SWPadnos_> um -eyah
[09:01:04] <cradek> this assumes all the axis limits are the same
[09:01:16] <cradek> so I think it clamps to the TRAJ limit
[09:01:27] <SWPadnos_> yes, it does
[09:02:12] <cradek> so it's a simple matter of ... putting the right code here and taking out the wrong code
[09:02:49] <jmkasunich> cradek: I ran some experiments that say it does respect inidividual axis limits
[09:03:00] <cradek> really? during FO?
[09:03:03] <jmkasunich> at least when scale = 1.0 (FO = 100%)
[09:03:05] <cradek> oh
[09:03:09] <cradek> I know that works :-)
[09:03:20] <jmkasunich> I set Z limit to 0.05, X and Y to 0.5
[09:03:23] <cradek> it would be very obvious on my mill - Z would stall
[09:03:36] <cradek> I'm glad you verified it
[09:03:39] <jmkasunich> made it even more obvious
[09:03:58] <cradek> you tried coordinated moves too, right?
[09:04:09] <jmkasunich> but that means the limit I was seeing can't possibly be line 417
[09:04:10] <jmkasunich> yes
[09:04:24] <jmkasunich> angled lines limit properly
[09:04:33] <cradek> good
[09:04:44] <jmkasunich> I didn't write a test program, probalby should to verify for sure
[09:04:59] <jmkasunich> for instance a line with 1/10 slope, and 1/1 slope,
[09:05:07] <jmkasunich> the first should go fast
[09:05:10] <jmkasunich> the second slow
[09:05:30] <jmkasunich> 2/10 slope should be inbetween
[09:05:53] <jmkasunich> hell, I can just do mdi
[09:05:55] <jmkasunich> stand by
[09:07:08] <SWPadnos_> you should be able to copy/paste whatever you enter in axis - it keeps a log of mdi commands
[09:07:23] <SWPadnos_> history, sorry
[09:09:47] <jmkasunich> yeah, it works
[09:09:52] <cradek> good
[09:10:08] <cradek> the canon is right
[09:10:18] <jmkasunich> with FO = 100, it limits such that no axis exceeds limit, but goes as fast as possible
[09:10:31] <jmkasunich> so if X has a high limit and Z a low one, X only moves go fast
[09:10:43] <cradek> that's thanks to getStraightVelocity in emccanon.cc
[09:10:45] <jmkasunich> combined XZ moves limit based on the amount of Z
[09:11:17] <cradek> there is per-axis vScale stuff commented out all over the place
[09:11:25] <jmkasunich> what file?
[09:11:33] <cradek> motion/usrmotintf.cc for one
[09:11:50] <cradek> task/taskintf.cc
[09:11:54] <cradek> look for axVscale
[09:11:57] <jmkasunich> gimme a line number
[09:12:18] <cradek> taskintf.cc:774
[09:12:26] <cradek> :q
[09:12:27] <cradek> oops
[09:12:39] <jmkasunich> heh, I thought you said usrmotintf
[09:12:48] <SWPadnos_> usrmotintf is just a status print function
[09:12:54] <SWPadnos_> the comment that is
[09:12:55] <jmkasunich> yeah
[09:13:00] <cradek> maybe this was never used
[09:13:08] <cradek> maybe someone just started putting it in
[09:13:09] <jmkasunich> thats why I wanted to see lines, I thought they were irrelevent
[09:13:51] <jmkasunich> I probably commented that out
[09:14:13] <jmkasunich> I have no idea what the per-axis scales are about
[09:14:20] <jmkasunich> completely undocumented
[09:14:38] <SWPadnos_> avVscale occurs 3 times in the emc2 tree
[09:14:55] <SWPadnos_> motion.h (commented out - in a struct)
[09:15:33] <SWPadnos_> taskintf.cc - in the status update func (since the vars aren't in the struct any more)
[09:15:47] <SWPadnos_> and usrmotintf.cc - status print
[09:15:50] <jmkasunich> motion.h is a good file - it defines the interface between userspace and the motion controller
[09:16:10] <SWPadnos_> I'm about to look for occurrences in emc1, and see where they're missing ;)
[09:16:24] <jmkasunich> notably - tp and tc don't have even commented out references to them
[09:17:42] <jmkasunich> I see them being set to 1.0, and to the global scale value
[09:17:52] <SWPadnos_> yep - then never used
[09:18:39] <SWPadnos_> hmm - perhaps those are "outputs" for status only, not the controlling variables
[09:19:42] <jmkasunich> I think they were to allow for never-implemented per-axis overrides
[09:19:54] <SWPadnos_> ok - could be
[09:19:54] <jmkasunich> a red herring related to this problem
[09:20:44] <jmkasunich> its gotta be in tp.c or tc.c
[09:20:53] <jmkasunich> they are the files that compute new positions
[09:21:00] <cradek> I can't even figure out how the scale is applied
[09:21:31] <cradek> if I didn't know it works, I would say it's not in here
[09:23:03] <jmkasunich> command.c line 876
[09:23:09] <jmkasunich> that executes a FO command
[09:23:26] <jmkasunich> sets qVscale which is used by the free mode TP (jogs) which works
[09:23:38] <jmkasunich> and calls tpSetVscale for the coord mode TP
[09:23:41] <cradek> and tpSetVscale which sets tp->vScale
[09:24:18] <jmkasunich> which is used all over tp.c and tc.c
[09:24:39] <SWPadnos_> all over = 7 occurrences
[09:24:54] <cradek> thank you SWPadnos_ aka wc
[09:25:03] <SWPadnos_> heh - that's me (simple tasks)
[09:25:29] <jmkasunich> my grep had 10 hits in tp and 15 in tc
[09:25:48] <cradek> it has to be applied in tc.c but it's not
[09:25:49] <jmkasunich> oops, my grep wasn't specific enough (just did vScale)
[09:26:18] <SWPadnos_> kate has a goof recursive grep tool (the find in files tab)
[09:26:22] <SWPadnos_> good, not goof
[09:27:06] <jmkasunich> where is that tool?
[09:28:17] <SWPadnos_> the find in files tab is on the bottom of my kate window
[09:28:21] <SWPadnos_> next to terminal
[09:28:28] <jmkasunich> hmm, joint (axis) velocity limits come down as EMCMOT_SET_JOINT_VEL_LIMIT commands
[09:28:36] <jmkasunich> duh,I was looking at the top
[09:28:59] <jmkasunich> cool, I learned something new today
[09:29:13] <SWPadnos_> heh - did you ever use the terminal?
[09:29:23] <jmkasunich> anyway, those commands are processed at command.c 818
[09:29:37] <jmkasunich> no, I just keep a couple of shells open
[09:30:02] <jmkasunich> kate on about half the screen, shells and IRC window on the other half
[09:30:04] <SWPadnos_> yep - the kate term is convenient because it opens in the file directory (so make or testing is easy)
[09:30:40] <jmkasunich> command.c doesn't send joint limits to the tp at all
[09:30:54] <jmkasunich> so how the heck is the limiting happening?
[09:31:31] <cradek> you mean without FO?
[09:31:39] <cradek> I understand that part
[09:31:57] <jmkasunich> yeah, with FO=100%, how does it know to run horizontal lines fast and vertical ones slow
[09:32:11] <jmkasunich> if it never sees the axis limits
[09:32:20] <cradek> the canon vel msg is sent in
[09:32:36] <jmkasunich> in to where from where
[09:32:43] <jmkasunich> I can't read your mind
[09:32:50] <cradek> from emccanon.cc line 457
[09:32:54] <jmkasunich> motion doesn't know anything about canon
[09:32:59] <jmkasunich> ok, let me open that
[09:33:22] <cradek> a EMC_TRAJ_SET_VELOCITY message is sent
[09:33:44] <cradek> when needed, before every segment or arc
[09:33:55] <cradek> I think you can even see those in the debug output
[09:33:56] <jmkasunich> huh? emccannon.cc line 457 is part of a probe command
[09:34:10] <cradek> oops
[09:34:12] <cradek> go up a page
[09:34:21] <cradek> line 404
[09:34:22] <cradek> same code
[09:34:26] <jmkasunich> ok, same thing for lines...
[09:34:49] <jmkasunich> so this has nothing at all to do with the tp
[09:34:54] <cradek> the math is above in getStraightVelocity
[09:34:57] <cradek> *right*
[09:35:24] <jmkasunich> so the speed that it sets is the target speed, assuming FO = 100%
[09:35:31] <cradek> yes
[09:35:39] <cradek> and this all works right
[09:35:46] <jmkasunich> then for any FO > 100%, you are fucked
[09:35:50] <cradek> but FO is another story because the TP has to do it
[09:35:53] <SWPadnos_> and then that gets multiplied by FO
[09:36:09] <cradek> fucked only if your axes are different maxvels I think
[09:36:20] <jmkasunich> I bet not
[09:36:53] <jmkasunich> this code sets a velocity that is the lesser of the Fword velocity, or any axis (taking into account the direction of the line)
[09:36:57] <jmkasunich> right?
[09:37:00] <SWPadnos_> actually, it limits to the max used axis vel, not the vector sum (along the requested path) of the used axes
[09:37:12] <cradek> jmkasunich: yes
[09:37:23] <SWPadnos_> yes
[09:37:38] <jmkasunich> so if it the Fword value, there might be headroom to allow for FO > 100%
[09:37:54] <cradek> yes
[09:38:06] <jmkasunich> but if it is an axis (whether they are the same or not), then multiplying it by FO>100% is gonna exceed the limit
[09:38:17] <cradek> in that case, it must not speed up
[09:38:35] <jmkasunich> but how is the TP to know which case it was
[09:38:58] <jmkasunich> and even if it was the Fword limit, for all the TP knows, the axis limit is only 2% higher
[09:39:09] <cradek> it has to assume requested (F word) *= FO and then do the same calculation
[09:39:41] <jmkasunich> "the same calculation" meaning do in RT the same thing that emccannon.cc just did in user space
[09:39:44] <cradek> yes
[09:39:57] <jmkasunich> if you are gonna do that, then why do it in userspace at all?
[09:40:01] <cradek> if you're scaling up
[09:40:47] <SWPadnos_> wherever the FO is multiplied in, that's where the check has to go.
[09:40:56] <cradek> SWPadnos_: I can't find it...
[09:41:02] <jmkasunich> and FO must be multiplied in in RT
[09:41:13] <cradek> yes
[09:41:15] <SWPadnos_> yeah - it may have been the line in tp.c
[09:41:17] <SWPadnos_> yep
[09:41:20] <cradek> because that's how we pause for instance
[09:41:46] <jmkasunich> yep, and because FO can't wait for a queued move to finish, it takes place even in the middle of a move
[09:42:06] <cradek> right
[09:42:26] <jmkasunich> so what emcmot command corresponds to sendVelMsg
[09:42:37] <SWPadnos_> to do it the "right" way, the RT code would need to know how to combine axes to get a resulting tool speed (ie, kins)
[09:43:03] <cradek> * cradek quietly sets his max override to 1.0 and slinks off
[09:43:08] <SWPadnos_> actually, kins derivatives
[09:43:16] <jmkasunich> heh, this user space code has no clue about kins, and would break terribly with non-trivial kins
[09:43:23] <SWPadnos_> yes
[09:43:27] <SWPadnos_> I noticed that ;)
[09:44:30] <jmkasunich> oh jeez... that sendVelMsg is still several layers removed from the RT code
[09:44:45] <jmkasunich> interp_list.append(velMsg)
[09:45:09] <cradek> yeah
[09:45:14] <cradek> I did trace it into tc->vScale
[09:45:19] <cradek> err
[09:45:22] <cradek> no, wrong thing
[09:45:36] <cradek> * cradek reads the screen
[09:45:38] <jmkasunich> heh, first you gotta trace it to usermotintf
[09:45:48] <jmkasunich> from there it goes to command.c
[09:46:15] <jmkasunich> but it must map to one of the commands in the enum at motion.h line 101
[09:46:22] <jmkasunich> that is all the motion controller understands
[09:46:43] <jmkasunich> I'm gonna guess its EMCMOT_SET_VEL
[09:46:54] <SWPadnos_> EMC_TRAJ_SET_VELOCITY
[09:47:01] <SWPadnos_> that's what it looked like to me
[09:47:11] <jmkasunich> that isn't an emcmot command
[09:47:23] <jmkasunich> (it may be the intermediate link)
[09:47:34] <SWPadnos_> it's the message type
[09:47:47] <jmkasunich> NML message, not emcmot command
[09:47:50] <jmkasunich> two different things
[09:47:55] <SWPadnos_> yes indeed
[09:47:57] <jmkasunich> usermotintf is tha translator
[09:48:38] <SWPadnos_> are you looking at emc1 or emc2?
[09:48:59] <jmkasunich> ok, emcTrajSetVelocity() in taskintf.cc issues EMCMOT_SET_VEL
[09:49:05] <jmkasunich> emc2 of course
[09:49:23] <SWPadnos_> ok
[09:49:40] <jmkasunich> * jmkasunich doesn't give a flying fuck about emc1 ;-)
[09:49:49] <SWPadnos_> only used for reference, of course ;)
[09:49:58] <jmkasunich> well yes, there is that
[09:50:01] <jmkasunich> ;-)
[09:51:22] <jmkasunich> man, a day in the life of a velocity command is quite a swirl
[09:51:34] <SWPadnos_> man - there's some terrible C++ code
[09:51:46] <jmkasunich> you noticed...
[09:51:52] <cradek> it is in fact EMCMOT_SET_VEL
[09:51:53] <SWPadnos_> looking the actual interp::append command
[09:51:56] <jmkasunich> think how I feel, I don't know C++
[09:52:12] <cradek> Itaskintf.cc:891
[09:52:19] <cradek> taskintf.cc:891
[09:52:21] <SWPadnos_> even worse (hint: look for ::func_name to find class member functions)
[09:52:42] <jmkasunich> cradek: yep...
[09:52:59] <jmkasunich> you followed it down from emccanon.c, and I followed it up from RT
[09:53:04] <jmkasunich> we met here ;-)
[09:53:10] <SWPadnos_> and I want back the way I came
[09:53:14] <SWPadnos_> went
[09:53:22] <SWPadnos_> either, I suppose ;)
[09:53:36] <jmkasunich> command.c 801 handles that command
[09:53:57] <jmkasunich> calls tsSetVmax() with the velocity
[09:54:18] <jmkasunich> but that is a scalar
[09:54:50] <jmkasunich> all info about whether a particular axis is causing the limit (or which one, or by how much you are avoiding the limit) is lost
[09:55:21] <jmkasunich> so when the TP gets an override and scales, it doesn't know how much room it has
[09:55:43] <jmkasunich> ignoring the kins issue for the moment....
[09:55:44] <SWPadnos_> by definition, it would have no room, since the limiting axis would be at its limit
[09:55:58] <cradek> SWPadnos_: in the case where you could scale up, the F word is the limit
[09:56:16] <jmkasunich> IF the user code limited the velocity, maybe the F word asked for 0.1 ipm, and no axis is even near a limit
[09:56:29] <SWPadnos_> yes -Ok
[09:56:41] <jmkasunich> seems the user code should send the desired (Fword) vel, and the max vel, separately
[09:56:55] <jmkasunich> and the TP should apply the scale to the desired, then apply the limit
[09:57:21] <cradek> SET_VEL could be sent with the requested feed (100%) and the max allowed multiplier
[09:57:30] <cradek> I think those are the only two numbers the tp needs to get this right
[09:57:31] <jmkasunich> thats another apporach
[09:57:39] <jmkasunich> same point, two numbers instead of one
[09:57:40] <cradek> then all the math is non-rt
[09:57:46] <cradek> yes
[09:57:58] <jmkasunich> the third (and correct, but harder to do) approach is to have the TP calculate the limit
[09:58:13] <cradek> yeah, SET_VEL would pretty much be the F word
[09:58:20] <jmkasunich> then user space only sends one number, the desired velocity
[09:58:35] <cradek> then the TP has to know all this about the machine...
[09:58:46] <jmkasunich> and the TP at least has a small chance of being able to take kins into account when calculating the limit
[09:58:55] <jmkasunich> user space doesn't even know about kins
[09:59:01] <cradek> ouch.
[09:59:34] <jmkasunich> at least I don't think so...
[09:59:40] <cradek> no clue here
[10:00:06] <cradek> we start by looking for a simple bug, and look where we end up
[10:00:45] <jmkasunich> there are very few simply bugs left in emc
[10:00:50] <SWPadnos_> I think the limiting code could be pretty simple
[10:01:16] <cradek> I'm sure I could do the simple but wrong fix (only trivkins)
[10:01:16] <SWPadnos_> it would definitely take longer though
[10:01:25] <cradek> it wouldn't actually be any more broken than it is now
[10:01:41] <jmkasunich> cradek: which approach would you take>
[10:01:42] <jmkasunich> ?
[10:01:46] <cradek> send in the two numbers
[10:02:05] <jmkasunich> max and desired (IMHO)
[10:02:16] <SWPadnos> phone
[10:02:19] <jmkasunich> or desired and max override
[10:02:29] <cradek> any combination of those
[10:03:08] <jmkasunich> pros: we could do it today (lotta files to touch tho)
[10:03:20] <jmkasunich> pros: fixes the problem for trivkins
[10:03:31] <jmkasunich> cons: doesn't fix for non-trivkins
[10:03:49] <jmkasunich> cons: the 2 numbers thing actually make the proper fix messier
[10:04:10] <jmkasunich> (or we would just revert it if and when we get a proper fix)
[10:04:37] <jmkasunich> the proper fix would actually touch fewer files
[10:04:45] <jmkasunich> remove limiting in emccannon.cc
[10:05:02] <jmkasunich> no changes to the nml message, no changes to any of the user-RT comms stuff
[10:05:08] <jmkasunich> change the TP
[10:05:11] <cradek> I still don't see where the tp does the actual scaling
[10:05:23] <SWPadnos_> that last line - change the tp ;)
[10:05:29] <jmkasunich> lemme find it
[10:05:41] <cradek> does tp even have access to all the ini's axis specifics?
[10:06:39] <jmkasunich> tp is in realtime
[10:06:48] <jmkasunich> it doesn't get anything that doesn't pass thru command.c
[10:07:08] <jmkasunich> and command.c doesn't process any command that isn't in that enum in motion.c:line 101
[10:08:04] <jmkasunich> the actual application of scale is at tc.c line 410 I think
[10:08:27] <jmkasunich> maybe not
[10:08:37] <cradek> that's just a clamp
[10:09:17] <cradek> I guess it's possible that assignment always triggers
[10:09:48] <cradek> I didn't consider that
[10:10:02] <cradek> I don't understand what discr does right above, and I think that's the key
[10:10:25] <jmkasunich> seems screwy that it would always trigger
[10:10:31] <cradek> yeah.
[10:10:44] <cradek> but that's the only use of vScale that I can see
[10:11:22] <jmkasunich> that discr thing could sure use a comment or two
[10:11:34] <cradek> it's years too late for that, isn't it
[10:12:19] <jmkasunich> ok, 0.5 vel cycletime = the distance we would travel if we stopped in one cycle
[10:12:32] <jmkasunich> toGo is how far we have to go in this move
[10:12:43] <jmkasunich> obviously
[10:13:01] <SWPadnos_> discr tells whether the current move is long enough to allow for decel to 0
[10:13:17] <SWPadnos_> or to accel (decel) to the new velocity
[10:13:22] <cradek> if you guys are sure, please add those comments
[10:13:58] <jmkasunich> not sure
[10:14:23] <SWPadnos_> heh - me either. I'm going through the accel formulas and this particular implementation in my head
[10:14:24] <jmkasunich> just thinking out loud, trying to figure out what they are doing
[10:15:11] <jmkasunich> what throws me is that normally the calc for "can we stop in time" needs to consider the accel limit, and not the cycle time
[10:15:39] <jmkasunich> this seems to assume that we can stop in one cycle, and calcs how far we will travel if we do
[10:15:45] <SWPadnos_> the first if is checking whether there is enough time to decel to 0 in this cycle
[10:16:06] <jmkasunich> are you sure?
[10:16:07] <SWPadnos_> it's 0.5 * (distance at this vel during a cycle)
[10:16:21] <SWPadnos_> cycle time * velocity is distance
[10:16:39] <jmkasunich> yea, and half that because they assume you will be stopped at the end of the cycle
[10:16:47] <SWPadnos_> and if that's more than the remaining distance, it triggers the zero speed case
[10:16:50] <jmkasunich> average velocity = half of current
[10:17:01] <SWPadnos_> no - because d = 1/2 At^2
[10:17:12] <jmkasunich> A isn't used there anywhere
[10:17:19] <jmkasunich> that's what I was just saying
[10:17:29] <SWPadnos_> true enough
[10:17:57] <jmkasunich> however, look at the second discr calc (in the else)
[10:18:17] <jmkasunich> there is a T^2 in there
[10:18:23] <jmkasunich> and an Amax
[10:18:37] <SWPadnos_> yep
[10:19:12] <jmkasunich> discr is a singularly poor variable name, I haven't a clue what they are doing
[10:19:33] <SWPadnos_> they're discriminating between two possible functions
[10:19:38] <SWPadnos_> it is a stupid name
[10:19:48] <SWPadnos_> or - two possible cases
[10:20:01] <jmkasunich> scuse me, gotta pee my ears off
[10:20:09] <SWPadnos_> heh - just did ;)
[10:21:21] <SWPadnos_> damn - I've got to run. I'll be back in a few hours
[10:21:26] <SWPadnos_> SWPadnos_ is now known as SWP_Away
[10:23:30] <cradek> I sure miss sim
[10:23:38] <cradek> it's impossible to debug anything on the rt side
[10:23:58] <rayh> what happened to sim?
[10:24:05] <cradek> emc2 has never had it
[10:24:58] <rayh> ah the sim I saw is only a HAL thing.
[10:28:29] <jmkasunich> cradek: you mean you want to run on a box without RTOS?
[10:28:48] <cradek> that too, but right now I want to be able to attach to everything with the debugger
[10:29:09] <jmkasunich> * jmkasunich doesn't believe in debuggers
[10:29:17] <cradek> ha
[10:32:22] <jmkasunich> heh, it doesn't help that discr is a length after the first calc, and time^2 after the second
[10:33:47] <jmkasunich> ok, the next one takes sqrt(discr), so that is a time
[10:40:40] <jmkasunich> face it, tcRunCycle is just some nasty code
[10:40:56] <cradek> I think that assignment does always happen
[10:41:20] <cradek> well, not always, but often
[10:41:20] <jmkasunich> talking about line 411?
[10:41:29] <cradek> newVel = (tc->vMax - tc->preVMax) * tc->vScale;
[10:41:37] <cradek> (I switched to emc1 so my line numbers are wrong)
[10:41:57] <jmkasunich> I don't buy that
[10:42:03] <jmkasunich> look at the next line
[10:42:14] <jmkasunich> isScaleDecel is not gonna be on all the time
[10:42:50] <cradek> the debugger says it's on all the time while running...
[10:43:06] <jmkasunich> how are you checking it?
[10:43:16] <cradek> I'm just printing it
[10:43:23] <jmkasunich> 1000 times a second?
[10:43:39] <cradek> something like that, probably
[10:45:23] <cradek> I'm going to change that line to *1.0 and see if FO stops working
[10:45:32] <cradek> I bet it will
[10:45:36] <jmkasunich> I think I'm gonna instrument this and look at it with halscope
[10:45:39] <rayh> jmkasunich: I'm working on the "watch" page. What all do you want to be able to watch?
[10:45:44] <jmkasunich> sounds like a good test
[10:45:54] <cradek> * cradek shoots into the darkness
[10:45:55] <jmkasunich> ray: buried in the guts of the TP right now
[10:46:05] <rayh> k
[10:48:14] <jmkasunich> cradek: just to let you know about a hook that is in there...
[10:48:31] <jmkasunich> control.c line 1898
[10:48:32] <cradek> jmkasunich: that does in fact break FO and pause
[10:48:41] <cradek> and abort
[10:48:50] <jmkasunich> and abort? wow
[10:49:31] <cradek> ok, that's where vScale is applied
[10:50:37] <cradek> so for the two number hack, we could add one line of code here (after adding the second number to the tc struct)
[10:50:47] <jmkasunich> something is still very wrong
[10:51:04] <cradek> the whole tp borders on very wrong
[10:51:16] <jmkasunich> if that line is always being applied, then the entire complex calcualtion of newVel up above is being wasted
[10:51:29] <cradek> it's not always
[10:51:38] <cradek> I think when stopping I saw isScaleDecel=0
[10:52:00] <cradek> hard to tell, they go by so fast
[10:52:20] <jmkasunich> I'm making newVal before that if available on a hal param
[10:52:27] <jmkasunich> and newVal after it on another
[10:52:33] <jmkasunich> so I can scope em both
[10:52:34] <cradek> cool
[10:53:45] <jmkasunich> are you running a program, or just MDI?
[10:54:13] <cradek> a program
[10:56:00] <cradek> I need to go do something else for a while... be back later
[10:56:08] <jmkasunich> ok
[11:07:01] <jmkasunich> hmm, paul is on #emc (as himself)... first time in a while
[11:07:05] <jmkasunich> * jmkasunich lurks
[11:07:38] <cradek> cool
[11:08:39] <cradek> * cradek is bad at lurking
[11:08:50] <jmkasunich> heh
[11:08:57] <jmkasunich> are you really back?
[11:09:06] <jmkasunich> or still doing something else
[11:09:09] <cradek> no, I never left
[11:09:27] <jmkasunich> found some stuff with the scope, dunno what it means yet
[11:09:39] <jmkasunich> you going away, or staying?
[11:10:03] <cradek> staying I guess
[11:10:09] <jmkasunich> ok
[11:10:10] <cradek> tell me what you found!
[11:10:24] <jmkasunich> the value of newVel before the if, is usually extremely high
[11:10:44] <jmkasunich> I'm not sure, but it might be the velocity need to reach the endpoint in one cycle time
[11:10:47] <jmkasunich> or something like that
[11:11:03] <jmkasunich> as you approach the endpoint, it decreases
[11:11:17] <jmkasunich> the shape is like a parabola lying on its side, open end to the left
[11:11:17] <cradek> ok...
[11:11:38] <cradek> that makes sense
[11:11:51] <jmkasunich> and until the last tiny bit of the move, the value is well above the clamp, so the clamp dominates
[11:12:02] <cradek> so when it gets low enough, FO is irrelevant
[11:12:05] <cradek> oop
[11:12:14] <cradek> no, that is waht I meant
[11:12:26] <jmkasunich> yeah
[11:12:46] <cradek> that would explain why I saw it usually 1 except when stopping
[11:12:50] <jmkasunich> could be that is the part when you are decelling to zero, so FO is irrelevant, you just want to decel as fast as possible
[11:16:46] <jmkasunich> I just thought of a better guess at what the unclamped newVel is
[11:17:17] <jmkasunich> it is "if you want to stop at the proper spot, you can be going this fast but not faster"
[11:17:47] <jmkasunich> and as such it is a function of the max accel (decel actually) and the distance left to go
[11:18:50] <jmkasunich> agreed about that debug - I put that in ages ago and should have removed it.... thanks
[11:18:55] <cradek> np
[11:19:08] <cradek> please put your best guesses in comments in that file
[11:19:13] <cradek> I think that would be great
[11:19:57] <jmkasunich> paul is stirring the pot
[11:20:06] <cradek> I'm not biting
[11:21:02] <jmkasunich> hit him with a bit of a snub
[11:21:10] <jmkasunich> (like a club, but quieter)
[11:21:21] <cradek> <ironic statement><noun>I'm</noun> not <verb>biting</verb></ironic statement>
[11:21:45] <cradek> sorry
[11:21:55] <jmkasunich> lol
[11:21:56] <cradek> (I think xml is silly)
[11:22:00] <jmkasunich> took me a moment to get it
[11:22:35] <jmkasunich> this vcp thing I'm working on involves a bit of heirarchy, and would be more of a candidate for XML than hal
[11:22:43] <jmkasunich> but I'm just using { and }
[11:22:47] <jmkasunich> widget {
[11:22:58] <jmkasunich> attribute_name = value
[11:23:00] <jmkasunich> attribute_name = value
[11:23:08] <jmkasunich> child_widget {
[11:23:16] <jmkasunich> etc
[11:23:20] <jmkasunich> }
[11:23:22] <jmkasunich> {
[11:23:24] <jmkasunich> oops
[11:23:25] <jmkasunich> }
[11:23:45] <cradek> yeah that sounds like a candidate
[11:23:52] <cradek> I think xml is ok for machine-generated stuff
[11:23:55] <jmkasunich> easier to read imo
[11:24:02] <cradek> but if you expect a human to write or edit the file, it's terrible
[11:24:10] <jmkasunich> exactly - not intended to be read or written by humans
[11:24:28] <jmkasunich> and since I'm not fond of wizard and such, I want human friendly formats
[11:24:59] <cradek> yeah.
[11:26:24] <jmkasunich> you know, I'd much rather be working on that right now... :-(
[11:28:14] <cradek> ok, now I'm off
[11:28:33] <jmkasunich> heh, I think I am too... get some food, then code some vcp
[11:28:42] <jmkasunich> we learned some things today
[11:28:53] <jmkasunich> just wish I knew what they were
[13:56:18] <SWP_Away> SWP_Away is now known as SWPadnos_
[13:56:43] <SWPadnos_> hi guys - anyone still around?
[13:57:10] <SWPadnos_> (with names, so you get interrupted: jmkasunich cradek)
[22:33:49] <chinamill> * chinamill is away: Will be running between the computer and the mill
[23:08:49] <chinamill> * chinamill is away: eating