#emc-devel | Logs for 2005-12-01

[13:47:13] <rayh> hey Chris. Thanks for setting this up.
[13:47:36] <cradek> no problem
[13:47:53] <cradek> sometimes the #emc channel gets noisy (with general linux questions usually)
[13:48:33] <alex_joni> and OT stuff
[13:50:27] <rayh> I'm more and more convinced that we will need subdirs in configs
[13:50:43] <alex_joni> ok.. I can assign to that
[13:50:48] <rayh> by the time you get a couple of hal files, a clp and such
[13:51:01] <alex_joni> but it'll be a few days.. I hope I'll be better lateron
[13:52:12] <rayh> No problem. I can handle the stuff in the mean time.
[13:57:18] <alex_joni> http://sourceforge.net/tracker/index.php?func=detail&aid=1370927&group_id=6744&atid=356744
[13:57:21] <alex_joni> how does that sound?
[13:57:59] <rayh> looking
[14:28:02] <SWPadnos_> hey rayh - did you get the latest ppmc hal files?
[14:29:16] <rayh> Yes I did. Not had a chance to test yet. will in a few minutes.
[14:29:25] <rayh> Thanks for the work on these.
[14:30:29] <SWPadnos_> no problem - that fixed the stupid following errors ofr me though :)
[14:31:41] <rayh> Ho WAH! It works.
[14:32:35] <SWPadnos_> yep - changing pid<n>.max_output from 1 to {AXIS_<n>]MAX_VELOCITY was the fix
[14:32:57] <SWPadnos_> the PID was limited to 1, but max velocity limited to 1.2 by default
[14:33:56] <SWPadnos_> at least it was a stupid configuration error (that took 6 hours to find), rather than a driver error (which probably would have taken only 5 hours to find) :)
[14:35:35] <rayh> doing some wierd stuff trying to run 3D_Chips
[14:35:45] <rayh> Runs cds okay
[14:35:47] <SWPadnos_> I never got that far :)
[14:35:57] <SWPadnos_> went to bed instead
[14:36:47] <rayh> I've got a question about building a EMC1 bridgeport setup.
[14:37:11] <rayh> That system used ini variables to set polarity and pin.
[14:37:20] <rayh> How can we do that with HAL?
[14:37:45] <SWPadnos_> the pins are connected via signals, and polarity is changeable on most inputs
[14:37:57] <SWPadnos_> right - one sec
[14:38:11] <SWPadnos_> (sorry - no coffee - didn't get the meaning of your question at first)
[14:38:19] <SWPadnos_> right now, you can't
[14:38:40] <cradek> can't what?
[14:38:48] <SWPadnos_> JMK and I (among others) have discussed the possibility of putting expressions into halcmd
[14:39:06] <SWPadnos_> you can't specify the spindle fwd output via the ini file
[14:39:12] <rayh> Okay. The problem is that the variable configuration can't be read into HAL
[14:39:35] <SWPadnos_> because you can't paste the number into a string in halcmd
[14:40:35] <SWPadnos_> what would be nice would be something like halcmd linksp spindle_on ==> ppmc.dout.[IO]SPINDLE_ON_BIT.out
[14:41:23] <rayh> It's not that bad.
[14:41:35] <rayh> those configs only worked for a second parport.
[14:41:58] <SWPadnos_> right - you still have a config param, it's just in the .hal file
[14:42:32] <SWPadnos_> and you probably want to make peole look at those settings if they're upgrading from emc1 to emc2
[14:54:53] <rayh> Following error in cds taskintf.cc 786: Error on axis 2, command number 399
[14:57:36] <SWPadnos_> funny -I ran it through once, and got no following errors
[14:57:54] <rayh> All over the place for me now.
[14:57:57] <SWPadnos_> switched to axis and full debugging, and I get an error about 1 second after you did ;)
[14:58:15] <SWPadnos_> I wonder if debug level has something to do with it
[15:00:07] <rayh> nope. set it to the lowest and it still faults.
[15:00:26] <SWPadnos_> ok. hmmm
[15:00:49] <SWPadnos_> I didn't notice the line number when it faulted before - I'm running itagain
[15:15:31] <SWPadnos_> so - 3d_chips ran fine the last time - with a shrunken axis window and a shrunken terminal for all those debug messages
[15:16:20] <cradek> SWPadnos_: I got glitches with emc2 when my PERIOD was a bit too low
[15:16:31] <cradek> SWPadnos_: when I moved the mouse around fast
[15:16:34] <SWPadnos_> I've got BASE_PERIOD at 500 uS
[15:16:43] <SWPadnos_> since it's a servo-esque card
[15:16:44] <cradek> SWPadnos_: jmk said that was because it couldn't get everything done it needed to
[15:16:48] <cradek> oh
[15:17:07] <SWPadnos_> I tried to get rid of BASE, but emc.run complained
[15:17:47] <SWPadnos_> I had run the file through with tkemc, then craved the bice plot window ;)
[15:18:03] <SWPadnos_> so ran with AXIS, and also turned debugging up to full
[15:18:40] <cradek> the gui should not matter unless something is wrong with your rt setup...
[15:19:02] <SWPadnos_> I agree - but I was thinking that X (being a hog of sorts) might make some difference
[15:19:11] <cradek> only if rt is setup wrong
[15:19:27] <cradek> everything else (X included) runs only when the realtime stuff is idle
[15:19:30] <SWPadnos_> well - I haven't messed with it - it's a BDI 4.30 install
[15:20:04] <SWPadnos_> do you know if any of the RT code does logging (based on debug level)?
[15:20:05] <cradek> I mean PERIOD, bios setup, etc
[15:20:21] <cradek> it can only log into the system's dmesg/syslog
[15:20:43] <cradek> I'm not sure if the ini debug level turns any of that on or off. I think it does.
[15:20:54] <SWPadnos_> yeah - I'm just looking for longshots here.
[15:21:13] <SWPadnos_> I've jus tgotten a second perfect run from Axis, and the third overall
[15:21:37] <cradek> is your bios setup right? All power management disabled, no shared system/video ram
[15:21:43] <SWPadnos_> actually, I am running remote X, so the network interrupts may cause some issues
[15:22:40] <cradek> do you actually have hardware hooked up?
[15:22:45] <cradek> I mean, servos/encoders?
[15:22:49] <SWPadnos_> a PPMC card, but no motors
[15:22:52] <cradek> ah
[15:23:02] <SWPadnos_> 180 IPM rapids though! :)
[15:23:28] <alex_joni> that's 4m/min ?
[15:23:40] <SWPadnos_> yep - closer to 4.5
[15:23:42] <cradek> % units 180inch m
[15:23:48] <cradek> * 4.572
[15:24:02] <cradek> * cradek introduces alex_joni to "units"
[15:24:18] <SWPadnos_> I probably won't want to run my Bridgeport that fast though ;)
[15:24:19] <cradek> tools are available to make it possible to talk to us americans
[15:24:20] <alex_joni> those aren't units
[15:24:27] <alex_joni> just a lame excuse for not using real units
[15:24:35] <alex_joni> ;-)
[15:24:41] <cradek> the program units
[15:24:48] <alex_joni> I know.. just teasing :D
[15:24:52] <SWPadnos_> hey - metric has only been official here for 30 years, give us a break
[15:25:02] <cradek> % units 180in/min hands/fortnight
[15:25:06] <cradek> * 907200
[15:25:22] <SWPadnos_> I guess you've got hand
[15:25:33] <alex_joni> what's a fortnight?
[15:25:36] <cradek> he could have said 907khpf instead
[15:25:48] <cradek> % units fortnight days
[15:25:50] <SWPadnos_> 2 weeks, silly non-UK native
[15:25:50] <cradek> * 14
[15:25:57] <alex_joni> 907k2hpf ;)
[15:26:45] <alex_joni> silly debate.. this whole units mess
[15:26:56] <cradek> I'm just saying there's a great program called units
[15:27:00] <cradek> no other debate afaic
[15:27:05] <SWPadnos_> yes - the boneneaded imperial holdouts are screwing up everything
[15:27:08] <alex_joni> yeah.. thanks for pointing that out
[15:27:15] <cradek> welcome
[15:27:18] <alex_joni> cradek: didn't mean our debate
[15:27:23] <alex_joni> generally speaking
[15:27:24] <SWPadnos_> losing spaceships and everything
[15:27:29] <SWPadnos_> ;)
[15:27:30] <alex_joni> and blaming history of course
[15:28:13] <SWPadnos_> not to change the subject, but has anyone else noticed that cds.ngc would break tools if you actually tried to run it?
[15:28:38] <SWPadnos_> it seems to be upside down or something
[15:31:02] <alex_joni> * alex_joni is upside down
[15:31:24] <SWPadnos_> that's because you're on the other side of the world ;)
[15:31:36] <alex_joni> not really.. but close enough
[15:31:55] <SWPadnos_> true - only 1/3 around, not 1/2
[15:32:11] <rayh> I'm getting unacceptable following error messages with ppmc
[15:32:28] <alex_joni> but now I'm actually lying in my bed, head facing east, so relative to your location it's more then upside/down I guess...
[15:32:34] <rayh> Set vel down to 1.2 (72 ipm)
[15:32:37] <SWPadnos_> what's your ferror set to in emc.ini?
[15:32:51] <rayh> 1.00 and min 0.100
[15:33:03] <SWPadnos_> I've just run cds twice more with no errors
[15:33:04] <rayh> 4000 input scale.
[15:33:07] <SWPadnos_> mm units?
[15:33:18] <rayh> inch
[15:33:21] <SWPadnos_> damn
[15:33:22] <cradek> is that 1.00 inch or 1.00/4000 inch?
[15:33:54] <SWPadnos_> I'm at 40k units/inch, and ferror=.050, min_feror = .010
[15:34:01] <alex_joni> should be 1.00 inch, it's still in emc before the /4000 happens.. I think
[15:34:05] <SWPadnos_> steps/inch, rather
[15:34:16] <SWPadnos_> yes - it should be in user units, I think
[15:34:21] <cradek> 1" is a pretty big following error
[15:34:23] <cradek> wow
[15:34:48] <rayh> It accumulates as you do longer moves.
[15:35:08] <alex_joni> sounds like PID isn't kicking in properly
[15:35:16] <alex_joni> what's I ?
[15:35:23] <rayh> I wouldn't think that would be impossible with usc
[15:35:41] <alex_joni> no PID in there? sorry.. I don't know the USC..
[15:36:05] <alex_joni> thought it's servo
[15:36:06] <SWPadnos_> you do need PID, with a P in the hundreds, and FF1 = 1
[15:36:24] <SWPadnos_> even with no motors attached and step outputs fed back to the encoders
[15:36:28] <rayh> ah. the damn ini I copied does not have pid.
[15:36:37] <alex_joni> problem solved :P
[15:36:39] <SWPadnos_> that should be in the .hal files
[15:36:49] <alex_joni> taken from the .ini I think ;)
[15:36:51] <rayh> this is where we WILL need some standardization on ini format for emc2
[15:36:59] <SWPadnos_> ppmc_motion.hal has P set to 100, FF1 set to 1
[15:37:08] <SWPadnos_> not taken from the INI, I think
[15:37:37] <rayh> I'm using your .hal file
[15:37:46] <rayh> or is that in core-servo
[15:37:58] <SWPadnos_> core_servo has P set to 100 for all 3 axes
[15:38:07] <SWPadnos_> ppmc_motion sets FF1 to 1 for all 3 axes
[15:38:19] <alex_joni> SWPadnos_: # set preliminary PID gains
[15:38:20] <alex_joni> setp pid.0.FF1 1
[15:38:20] <alex_joni> setp pid.1.FF1 1
[15:38:20] <alex_joni> setp pid.2.FF1 1
[15:38:27] <SWPadnos_> (yes - those things should be in some standard place)
[15:38:36] <alex_joni> sore_servo sounds like the place
[15:38:44] <alex_joni> and those should come from the .ini imho
[15:39:02] <SWPadnos_> yes - jmk and I just put them in the ppmc file to avoid changing unrelated files
[15:39:02] <rayh> So we're saying we can not tune using ini variables
[15:39:19] <SWPadnos_> you can, but the default emc.ini in emc2 has no pid values in it
[15:39:26] <SWPadnos_> we can certainly change that
[15:39:27] <alex_joni> I have this in my core_servo.hal
[15:39:28] <alex_joni> setp pid.0.Pgain 0.01
[15:39:28] <alex_joni> setp pid.0.Igain 0
[15:39:28] <alex_joni> setp pid.0.Dgain 0
[15:39:28] <alex_joni> setp pid.0.bias 0
[15:39:28] <alex_joni> setp pid.0.FF0 0
[15:39:30] <alex_joni> setp pid.0.FF1 0
[15:39:38] <alex_joni> maybe you didn't commit the Pgain 100 ?
[15:39:51] <SWPadnos_> yep - and the core_ppmc overrides the FF1 to 1
[15:39:58] <alex_joni> but not Pgain to 100
[15:40:00] <alex_joni> as you said
[15:40:07] <SWPadnos_> it's there, as of last night, around midnight my time
[15:40:14] <alex_joni> I just checked out
[15:40:23] <SWPadnos_> hmm
[15:40:25] <alex_joni> devel_access, before you ask
[15:40:34] <SWPadnos_> really? ;)
[15:40:52] <SWPadnos_> ok - I didn't check in the core_servo.hal file
[15:40:54] <alex_joni> yes. but where should it be? core_servo ?
[15:41:00] <alex_joni> heh.. see..
[15:41:15] <SWPadnos_> core_servo loads up the PID component, so it should set the PID values as well
[15:41:29] <alex_joni> if you do check in.. check in to use the values from the ini
[15:41:49] <alex_joni> and put those back in there, it's less confusing for users switching to emc2
[15:41:58] <SWPadnos_> well - I think those were removed by default so the ini wouldn't be cluttered for stepper users (or something)
[15:42:29] <SWPadnos_> this is where halcmd needs to have some better error handling, and an if statement
[15:42:57] <alex_joni> SWPadnos_: this is were different subdirs will come in handy
[15:43:03] <SWPadnos_> if error occurs setp pid.0.Pgain [AXIS_0]P then setp pid.0.Pgain 100
[15:43:55] <SWPadnos_> no -wait, we can be really tricky: setp pid.0.Pgain ([AXIS_0]P ? [AXIS_0]P : 100 ) :)
[15:45:24] <SWPadnos_> so - Ray - change those P values to 100 or more, and try again
[15:45:56] <rayh> no difference
[15:46:14] <SWPadnos_> odd.
[15:46:23] <alex_joni> 100 is even ;)
[15:46:34] <SWPadnos_> indeed
[15:47:04] <rayh> I set these in ppmc.hal right below the FF1 stuff
[15:47:04] <SWPadnos_> so - you have P=100, I=D=FF0=0, and FF1=1 on all axes?
[15:48:06] <alex_joni> try bin/halcmd show param pid
[15:48:38] <SWPadnos_> cradek: one more reason to have AXIS save a config file - restore the window position and size ;)
[15:50:09] <cradek> no, that's a function of the window manager
[15:50:12] <rayh> okay. the startup does NOT honor the setting in ppmc.hal
[15:50:36] <SWPadnos_> what order are they in in emc.ini?
[15:50:48] <alex_joni> the right one, or else it WILL complain
[15:50:59] <alex_joni> but maybe ppmc_motion.hal isn't called in the ini
[15:51:26] <SWPadnos_> it should be core_servo, ppmc_motion.hal, then ppmc_io.hal
[15:51:47] <alex_joni> what's the ini for this?
[15:51:58] <alex_joni> there isn't one in configs/ right?
[15:51:59] <SWPadnos_> I'm not sure that the order of the ppmc.* files matters, but core_servo definitely needs to be first, or it will complain
[15:52:02] <SWPadnos_> no
[15:52:11] <alex_joni> ok..
[15:52:25] <alex_joni> the order does matter because ppmc_motion installs the driver
[15:52:29] <alex_joni> and ppmc_io doesn't
[15:52:31] <SWPadnos_> true
[15:52:42] <alex_joni> so the order above is NEEDED
[15:53:09] <rayh> bin/halcmd does reset Pgain but made no difference.
[15:53:09] <SWPadnos_> yep - also ppmc_motion sets up a couple of signals that get connected in ppmc_io
[15:53:13] <SWPadnos_> (just like stg_* :) )
[15:54:20] <alex_joni> SWPadnos_: I noticed in the very first commits :D
[15:54:26] <SWPadnos_> heh
[15:54:34] <alex_joni> #load STG driver
[15:54:40] <alex_joni> loadrt hal_ppmc
[15:54:42] <alex_joni> ;-)
[15:54:46] <SWPadnos_> yep
[15:54:51] <alex_joni> but I don't mind..I did the same for the STG
[15:55:49] <SWPadnos_> this is another place where halcmd if statements would be good: if !loaded (hal_ppmc) call ppmc_motion.hal
[15:56:27] <SWPadnos_> and calls, of course
[15:56:54] <alex_joni> that's a strange bio-electronic mutation rayh is going through
[15:57:04] <rayh_ppmc_usc> # list of hal config files to run through halcmd
[15:57:04] <rayh_ppmc_usc> # files are executed in the order in which they appear
[15:57:05] <rayh_ppmc_usc> HALFILE = core_servo.hal
[15:57:05] <rayh_ppmc_usc> HALFILE = ppmc_motion.hal
[15:57:05] <rayh_ppmc_usc> HALFILE = ppmc_io.hal
[15:57:18] <SWPadnos_> well - that looks right ;)
[15:57:18] <alex_joni> sounds about right
[15:57:47] <rayh_ppmc_usc> # set preliminary PID gains
[15:57:47] <rayh_ppmc_usc> setp pid.0.FF1 1
[15:57:47] <rayh_ppmc_usc> setp pid.1.FF1 1
[15:57:48] <rayh_ppmc_usc> setp pid.2.FF1 1
[15:57:48] <rayh_ppmc_usc> setp pid.0.Pgain 200
[15:57:49] <rayh_ppmc_usc> setp pid.1.Pgain 200
[15:57:49] <rayh_ppmc_usc> setp pid.2.Pgain 200
[15:57:59] <rayh_ppmc_usc> in the motion hal
[15:58:00] <alex_joni> * alex_joni wonders..
[15:58:04] <SWPadnos_> I just noticed that I was running with test ferror numbers for the Z axis (ferror=1 min=.5)
[15:58:10] <alex_joni> this is the second setp
[15:58:23] <SWPadnos_> I changed them, and am now running cds again
[15:58:38] <SWPadnos_> the second setp works, if that's what you're wondering
[15:58:50] <alex_joni> yes.. that's what I'm wondering..
[15:59:07] <alex_joni> rayh: after executing that, does bin/halcmd show the right values?
[16:00:10] <rayh_ppmc_usc> no
[16:00:30] <rayh_ppmc_usc> 04 float -W 1.00000e-02 pid.0.Pgain
[16:00:51] <alex_joni> how about FF1 ?
[16:01:19] <rayh_ppmc_usc> shows 1
[16:01:28] <alex_joni> so that gets set..
[16:01:44] <alex_joni> wth doesn't Pgain get updated..
[16:02:04] <alex_joni> try some silly value, to see if halcmd complains: setp pid.0.Pgain 20a
[16:02:44] <rayh_ppmc_usc> g0 x8 kicks up the error at 5.2590 -- now I'll set Pgain with a halcmd.
[16:02:48] <SWPadnos_> ray - run halcmd -kf, then type 'setp ', double-click pid.0.Pgain, middle click, hit space, and type in 200
[16:02:48] <SWPadnos_> just to make sure there isn't some silly mis-spelling somewhere
[16:02:48] <SWPadnos_> (not that I saw one)
[16:03:03] <SWPadnos_> it should complain anyway - no parameter by that name
[16:03:14] <rayh_ppmc_usc> 04 float -W 2.00000e+02 pid.0.Pgain
[16:03:31] <alex_joni> same for pid.1 and pid.2
[16:04:27] <rayh_ppmc_usc> error at 5.2670
[16:04:39] <rayh_ppmc_usc> we didn't gain much.
[16:04:57] <SWPadnos_> what file are you running? (or is this with manual moves)
[16:05:20] <rayh_ppmc_usc> I don't see why halcmd -kf should make a difference
[16:05:27] <rayh_ppmc_usc> mdi g0 x8
[16:05:31] <SWPadnos_> it shouldn't
[16:05:33] <SWPadnos_> ok
[16:06:03] <rayh_ppmc_usc> * rayh_ppmc_usc trying a p of thousands
[16:06:10] <SWPadnos_> what's pid.0.maxoutput?
[16:06:58] <rayh_ppmc_usc> lost ground on that one.
[16:07:20] <rayh_ppmc_usc> 04 float -W 1.00000e+00 pid.0.maxoutput
[16:07:20] <rayh_ppmc_usc>
[16:07:29] <SWPadnos_> and what's max velocity?
[16:09:00] <SWPadnos_> (that's not available from halcmd, I think - check the ini)
[16:09:02] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.Dgain
[16:09:03] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.FF0
[16:09:03] <rayh_ppmc_usc> 04 float -W 1.00000e+00 pid.0.FF1
[16:09:03] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.Igain
[16:09:04] <rayh_ppmc_usc> 04 float -W 2.00000e+04 pid.0.Pgain
[16:09:04] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.bias
[16:09:06] <rayh_ppmc_usc> 04 float -W 5.00000e-04 pid.0.deadband
[16:09:08] <rayh_ppmc_usc> 04 s32 R- 0 pid.0.do-pid-calcs.time
[16:09:10] <rayh_ppmc_usc> 04 s32 RW 0 pid.0.do-pid-calcs.tmax
[16:09:12] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.maxcmdD
[16:09:14] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.maxerror
[16:09:16] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.maxerrorD
[16:09:18] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.maxerrorI
[16:09:20] <rayh_ppmc_usc> 04 float -W 1.00000e+00 pid.0.maxoutput
[16:10:17] <rayh_ppmc_usc> brb
[16:10:23] <SWPadnos_> ok
[16:11:07] <SWPadnos_> what I'd like to know is - why isn't the ppmc_io file doing *some* things?
[16:11:19] <SWPadnos_> it's connecting the enable, or there would be no motion at all
[16:11:30] <alex_joni> and putting FF1 to 1
[16:11:37] <alex_joni> initially it's set to 0
[16:12:36] <SWPadnos_> yep - that too
[16:13:23] <SWPadnos_> just had another perfect run - I only saw it fail once
[16:15:37] <SWPadnos_> brb
[16:16:25] <rayh_ppmc_usc> Should I be able to reset values of any of these pid variables in ppmc_motion.hal
[16:17:37] <alex_joni> yes you should
[16:25:19] <rayh_ppmc_usc> k found the problem output should be 10 not 1
[16:25:45] <alex_joni> working now?
[16:25:54] <rayh_ppmc_usc> I'll clean it up a bit and see what happens.
[16:26:30] <rayh_ppmc_usc> I believe that I could add PIDand the FF's to the ini file and use an ini reference to them.
[16:26:34] <rayh_ppmc_usc> Is that correct?
[16:27:24] <alex_joni> sure you could, and that would be correct
[16:27:49] <rayh_ppmc_usc> Okay. I'll work here for a bit.
[16:28:07] <SWPadnos_> the output should be set from the ini file [AXIS_n]MAX_VELOCITY
[16:28:14] <SWPadnos_> max pid output, that is
[16:29:54] <SWPadnos_> gah - it looks like that didn't get committed
[16:31:18] <SWPadnos_> duh - of course it didn't - I didn't commit core_servo.hal
[16:31:40] <alex_joni> SWPampy: getting old? :-)
[16:31:48] <SWPadnos_> too late for that ;)
[16:33:48] <SWPadnos_> well - let's see how that works
[16:34:21] <rayh_ppmc_usc> Are you planning to set the tuning parms from ini as well
[16:34:49] <SWPadnos_> maybe - I might want to make a ppmc.ini file
[16:35:04] <rayh_ppmc_usc> Got one here.
[16:35:09] <SWPadnos_> I've got a bunch of changes in my file though, so I didn't want to commit anything without reviewing it first
[16:35:22] <alex_joni> rayh_ppmc_usc: if you commit that one, commit directly to a ppmc/ dir
[16:35:29] <alex_joni> and I'll make it work afterwards.. ok?
[16:36:31] <rayh_ppmc_usc> Is, will there be a significant difference between usc and upc
[16:36:55] <rayh_ppmc_usc> I suppose the upc will have frequency and such.
[16:37:05] <SWPadnos_> only in motion - the outputs are called ppmc.0.pwm.n instead of ppmc.0.stepgen.n
[16:37:11] <SWPadnos_> yep, and the params are different as well
[16:37:15] <SWPadnos_> max duty and the like
[16:37:28] <SWPadnos_> but the IO names are the same
[16:37:41] <SWPadnos_> so ppmc_io should be unchanged
[16:37:44] <alex_joni> SWPadnos_: would it be possible to set them all ?
[16:38:07] <alex_joni> given that halcmd won't complain on the ones that don't exist?
[16:38:45] <SWPadnos_> no - the params don't exist for the stepper cards
[16:38:46] <SWPadnos_> you could try, but you'd just get errors
[16:39:06] <alex_joni> <alex_joni> given that halcmd won't complain on the ones that don't exist?
[16:39:07] <SWPadnos_> the'ye conceptually different
[16:39:42] <SWPadnos_> a group of PWMs share an update frequency, but have differnet duty cycles.
[16:40:00] <SWPadnos_> a group of stepgens share a pulse width, but have different frequencies
[16:40:10] <alex_joni> I see. so basicly you'll need 2 ppmc_motion.hal files ;)
[16:40:23] <alex_joni> I could live with that..
[16:40:24] <SWPadnos_> yes - usc_motion and ppmc_motion might make sense ;)
[16:40:35] <alex_joni> and ppmc_io.hal for all
[16:40:38] <SWPadnos_> (though the ppmc wer have now is aciually USC)
[16:40:42] <SWPadnos_> yep
[16:43:58] <rayh_ppmc_usc> I see bias is also gone from the ini
[16:44:21] <SWPadnos_> yeah - ther eshould probably be two inis - a servo.ini and a stepper.ini
[16:45:31] <rayh_ppmc_usc> I complained to jmk about that long ago. emc.run should be servo and generic.run should be stepper
[16:45:41] <rayh_ppmc_usc> if we are consistent between emc and emc2
[16:46:05] <SWPadnos_> ok - I didn't realize they were set up like that
[16:46:05] <rayh_ppmc_usc> servo.run and stepper.run would make more sense to me. but hey.
[16:46:12] <SWPadnos_> yep - me too
[16:46:22] <SWPadnos_> use a softlink for emc.ini
[16:46:27] <SWPadnos_> or .run
[16:46:40] <alex_joni> * alex_joni thinks it should be emc not emc.run ;)
[16:46:46] <SWPadnos_> that too ;)
[16:46:50] <alex_joni> no other software out there ending in .run
[16:47:09] <alex_joni> like cradek said :)
[16:47:25] <alex_joni> perhaps 'emc stepper' and 'emc servo'
[16:47:30] <alex_joni> or 'emc mazak'
[16:47:32] <rayh_ppmc_usc> deadband is gone also
[16:47:34] <alex_joni> something like that
[16:47:45] <alex_joni> emc.ini is for steppers I think
[16:47:49] <SWPadnos_> all the PID related settings are gone
[16:48:08] <rayh_ppmc_usc> but deadband is used for both steppers and servos.
[16:48:17] <alex_joni> not for steppers in emc2
[16:48:25] <alex_joni> as they don't have PID anymore..I think
[16:48:29] <rayh_ppmc_usc> It better be.
[16:48:56] <rayh_ppmc_usc> or does the generator sit idle at the nearest pulse
[16:49:12] <alex_joni> yes
[16:49:31] <rayh_ppmc_usc> and it always stops at the nearest?
[16:49:58] <alex_joni> deadband is used only for PID's
[16:50:13] <alex_joni> rayh_ppmc_usc: I think so, but it would be safer to ask jmk
[16:50:21] <rayh_ppmc_usc> okay
[16:50:40] <rayh_ppmc_usc> The concept of deadband is exactly the same for servos and steppers.
[16:51:06] <rayh_ppmc_usc> so if we compute it in the step generator we should compute it in the servo as well
[16:51:07] <alex_joni> I guess deadband = 1 step for steppers
[16:51:24] <rayh_ppmc_usc> no it should be a bit more than a half step
[16:51:24] <alex_joni> probably 1 encoder step in servo aswell
[16:51:33] <alex_joni> right
[16:53:18] <SWPadnos_> actually, you still need PID for steppers, or at least some version of it
[16:53:25] <alex_joni> how so?
[16:53:46] <SWPadnos_> the step generators can't generate the exact frequency you want, so you have to corect for it by bouncing back and forth between the two nearest
[16:54:07] <SWPadnos_> that requires feedback and some kind of simple PID
[16:55:02] <SWPadnos_> I think that's what jmk did in stepgen, but it doesn't work for external step generators (like the USC) - for those, you have to look at what was actually output, and correct for it
[17:01:54] <rayh_ppmc_usc> as I work on this ini file, is it appropriate to up INPUT_SCALE = 10000
[17:02:17] <rayh_ppmc_usc> cause folk aren't going to use it with 4000. that's parport range.
[17:02:31] <SWPadnos_> INPUT_SCALE should still be the number of encoder/step counts per user unit
[17:03:05] <rayh_ppmc_usc> Right. I was just thinking that 4k is really low for this board.'
[17:03:18] <SWPadnos_> no - it has no relevance to the board ;)
[17:03:27] <alex_joni> maybe someone uses high speed machining
[17:03:33] <alex_joni> low counts / unit..
[17:03:34] <SWPadnos_> I need 40k, because of my encoder resolution, drive ratio, and ballscrew TPI
[17:04:22] <SWPadnos_> that's one thing that HAL does for us - everything should be in user units until it goes to the hardware - that's the place where the scaling occurs
[17:04:49] <SWPadnos_> so putting a 1 into a ppmc stepgen means "1 user unit / sec velocity"
[17:05:05] <rayh_ppmc_usc> What has relevance is that this is a sample ppmc_usc system we are setting up.
[17:05:14] <alex_joni> SWPampy: I know, rayh was just wondering what defalt value he should put in the ini in CVS
[17:05:16] <rayh_ppmc_usc> It does not match any single machine.
[17:05:31] <alex_joni> s/defalt/default/
[17:05:33] <SWPadnos_> ok - well, go easy, I haven't had breakfast yet ;)
[17:05:40] <rayh_ppmc_usc> It's like the problem caused by emc.ini having a 4" z travel
[17:05:51] <rayh_ppmc_usc> You can not run any of our progrms with it as is.
[17:05:56] <SWPadnos_> heh - I noticed that one
[17:06:27] <SWPadnos_> actually, it should be alittle over the true range, like 5.0001, so you can actually ask for 5.0 without getting an error
[17:06:36] <rayh_ppmc_usc> What happens is that developers tend to get configs going for their machine and then commit.
[17:06:41] <SWPadnos_> (I got an error asking for 4.0)
[17:06:50] <rayh_ppmc_usc> I know I've done it a lot.
[17:06:53] <SWPadnos_> that's why I didn't commit my enc.ini ;)
[17:07:04] <alex_joni> enc.ini sounds fun :)
[17:07:05] <rayh_ppmc_usc> even the fabled FredP and WillS have done it.
[17:07:33] <SWPadnos_> right - have I mentioned that I haven't had breakfast?
[17:07:39] <SWPadnos_> and my fingers are frozen
[17:07:52] <SWPadnos_> maybe I'll turn up the heat, and make some nice hot cereal
[17:07:58] <alex_joni> SWPampy: stick them somewhere.. to heat them up :P
[17:08:03] <SWPadnos_> done
[17:08:13] <SWPadnos_> but it's hard to type that way
[17:08:35] <rayh_ppmc_usc> I'd email a truckers special bkfast but they don't fill you up much
[17:09:06] <SWPadnos_> anyway - thinking about reasonable values, a servo machine might be a 500 CPR encoder, with a 10 turn/inch drive, so maybe 20000 default?
[17:09:56] <rayh_ppmc_usc> k
[17:10:11] <rayh_ppmc_usc> does the following look okay for core_servo
[17:10:16] <rayh_ppmc_usc> setp pid.0.Pgain [AXIS_0]P
[17:10:16] <rayh_ppmc_usc> setp pid.0.Igain [AXIS_0]I
[17:10:17] <rayh_ppmc_usc> setp pid.0.Dgain [AXIS_0]D
[17:10:17] <rayh_ppmc_usc> setp pid.0.bias [AXIS_0]BIAS
[17:10:17] <rayh_ppmc_usc> setp pid.0.FF0 [AXIS_0]FF0
[17:10:17] <rayh_ppmc_usc> setp pid.0.FF1 [AXIS_0]FF1
[17:10:18] <rayh_ppmc_usc> setp pid.0.deadband [AXIS_0]DEADBAND
[17:10:27] <alex_joni> yes
[17:10:50] <SWPadnos_> looks good to me
[17:10:59] <rayh_ppmc_usc> I see that we assume that min and max output will be the same.
[17:11:31] <SWPadnos_> yes - the PID has only one - absolute magnitude
[17:12:01] <SWPadnos_> I suppose that should change, to account for non-symmetric Z axes
[17:12:05] <SWPadnos_> and the like
[17:12:45] <SWPadnos_> one other thing - the PID max output should probably be a little higher than the axis max_velocity
[17:13:08] <alex_joni> again HAL math ;)
[17:13:11] <SWPadnos_> PID may need to overshoot the requested velocity, to be able to "catch up"
[17:13:12] <SWPadnos_> yep
[17:13:35] <SWPadnos_> it would be nice to be able to do setp pid.0.FF1 *1.1
[17:13:39] <SWPadnos_> or -0.5
[17:13:46] <SWPadnos_> to modify it
[17:14:16] <alex_joni> -0.5 works right now
[17:14:26] <alex_joni> but probably will cause something you won't want :D
[17:16:41] <SWPadnos_> ibdeed ;)
[17:16:47] <SWPadnos_> no- indeed
[17:17:05] <alex_joni> get some breakfast already
[17:17:27] <SWPadnos_> just did - I'm holding thwe bowl to warm up my hands
[17:17:31] <rayh_ppmc_usc> it works.
[17:17:39] <SWPadnos_> cool
[17:17:47] <alex_joni> rayh_ppmc_usc: yay
[17:18:17] <SWPadnos_> that PID limit thing was a real pisser - took me hours to find it, because the damn thing wouldn't run for long enough for me to see the frequency on the scope
[17:18:47] <alex_joni> heh :)
[17:19:05] <SWPadnos_> I finally set the Z limit to 20 so it would run long enough
[17:19:23] <alex_joni> SWPadnos_: shouldn't the USC take care of the PID by itself?
[17:19:30] <alex_joni> talking theory right now..
[17:19:30] <SWPadnos_> no
[17:19:31] <rayh_ppmc_usc> I get an EMC_TOOL_ABORT when I try to run 3d chips.
[17:19:34] <alex_joni> in a perfect world
[17:19:34] <SWPadnos_> it's not a driver
[17:19:47] <alex_joni> just like stepgen
[17:19:50] <SWPadnos_> you would connect it to a Gecko or something, which would have its own PID loop
[17:19:52] <alex_joni> in hardware, not software
[17:20:11] <rayh_ppmc_usc> with cds following error again.
[17:20:14] <SWPadnos_> maybe - if you could set a floating point rate in the hardware
[17:20:22] <SWPadnos_> hm
[17:20:24] <alex_joni> ahh.. yes
[17:20:48] <rayh_ppmc_usc> joint 0 following error
[17:20:49] <rayh_ppmc_usc> taskintf.cc 786: Error on axis 0, command number 323
[17:20:49] <rayh_ppmc_usc> EMC_TOOL_ABORT
[17:21:02] <SWPadnos_> I haven't been able to run 3d_chips at all
[17:21:50] <rayh_ppmc_usc> Right that one trashes out near the first move.
[17:21:57] <SWPadnos_> and you have pid.n.max-output set to [AXIS_n]MAX_VELOCITY?
[17:22:20] <rayh_ppmc_usc> let me check to make certain that the values got loaded.
[17:23:24] <SWPadnos_> note that these values may get rewritten to default (in the ini file) when you exit from emc - some parameters aren't being loaded at all, but are still written with the defaults
[17:23:40] <SWPadnos_> like OUTPUT_SCALE
[17:23:58] <alex_joni> bleah :(
[17:24:04] <rayh_ppmc_usc> looks like it loaded values correctly
[17:24:23] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.Dgain
[17:24:23] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.FF0
[17:24:24] <rayh_ppmc_usc> 04 float -W 1.00000e+00 pid.0.FF1
[17:24:24] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.Igain
[17:24:24] <rayh_ppmc_usc> 04 float -W 2.50000e+02 pid.0.Pgain
[17:24:24] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.bias
[17:24:25] <rayh_ppmc_usc> 04 float -W 5.50000e-05 pid.0.deadband
[17:24:27] <rayh_ppmc_usc> 04 s32 R- 0 pid.0.do-pid-calcs.time
[17:24:29] <rayh_ppmc_usc> 04 s32 RW 0 pid.0.do-pid-calcs.tmax
[17:24:31] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.maxcmdD
[17:24:33] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.maxerror
[17:24:35] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.maxerrorD
[17:24:37] <rayh_ppmc_usc> 04 float -W 0.00000e+00 pid.0.maxerrorI
[17:24:39] <rayh_ppmc_usc> 04 float -W 1.00000e+01 pid.0.maxoutput
[17:24:41] <rayh_ppmc_usc>
[17:24:57] <SWPadnos_> nope - maxoutput is still 1
[17:25:01] <alex_joni> 10
[17:25:03] <SWPadnos_> what's max_velocity
[17:25:07] <SWPadnos_> oh yeah ;)
[17:25:23] <rayh_ppmc_usc> Ah
[17:25:30] <rayh_ppmc_usc> let me fix that.
[17:25:36] <alex_joni> it's 10 there, what's max_velocity ?
[17:25:37] <rayh_ppmc_usc> thanks.
[17:25:55] <alex_joni> 1.0e+01 = 10
[17:25:57] <SWPadnos_> yeah - sorry - I misread the exponent
[17:25:57] <rayh_ppmc_usc> At my age with emc, I know not to try to edit the ini while emc is running.
[17:26:16] <alex_joni> rayh_ppmc_usc: probably the best thing ;)
[17:26:22] <SWPadnos_> the trouble is that some values may get reset to default, even if you edit at teh right times
[17:26:28] <SWPadnos_> the
[17:26:53] <rayh_ppmc_usc> I've only had that problem with the tuning stuff in tkemc.
[17:27:37] <SWPadnos_> you know what - min_ferror and ferror are being overwritten (I think)
[17:29:00] <SWPadnos_> okj - they're being preserved (though they do get rewritten)
[17:30:51] <rayh_ppmc_usc> Where would I look with halcmd to see these?
[17:31:07] <alex_joni> those are in the ini
[17:31:23] <SWPadnos_> you can't - they're internal to the motion controller
[17:31:23] <rayh_ppmc_usc> and they are not used in the HAL?
[17:31:26] <SWPadnos_> nope
[17:31:42] <alex_joni> they are used in the motion controller
[17:31:49] <alex_joni> but you don't need to connect them to anything..
[17:31:51] <SWPadnos_> they should be settable (and viewable) through HAL, but they're not ATM
[17:32:01] <SWPadnos_> parameters can't be connected to anything
[17:32:17] <rayh_ppmc_usc> okay.
[17:32:33] <SWPadnos_> (which is a bummer, because I'd like to be able to group parameters so they can be changed more easily)
[17:32:34] <alex_joni> they should be viewable at the moment
[17:32:35] <alex_joni> axis_data->f_error = joint->ferror;
[17:32:35] <alex_joni> axis_data->f_error_lim = joint->ferror_limit;
[17:32:47] <SWPadnos_> I didn't see them dhow up there
[17:32:50] <SWPadnos_> show
[17:32:53] <alex_joni> under param, not pin
[17:32:54] <rayh_ppmc_usc> I'm beginning to think after another following error that we are dealing with an accel problem.
[17:33:11] <SWPadnos_> try G1X10F60
[17:33:16] <SWPadnos_> rather than g0X10
[17:33:44] <alex_joni> SWPadnos_: they are exported at axis_0.f_error , or something like that
[17:33:44] <alex_joni> param
[17:33:54] <SWPadnos_> those are outputs, I think
[17:34:27] <rayh_ppmc_usc> I'm attempting to run cds.ngc
[17:35:37] <SWPadnos_> yep - all axis.* params are R-, not -W
[17:36:08] <rayh_ppmc_usc> different place for the following error that time.
[17:36:37] <SWPadnos_> different from run to run, or from g0 to g1?
[17:37:00] <rayh_ppmc_usc> I'm just running the file as is.
[17:37:16] <rayh_ppmc_usc> i think its f10
[17:37:26] <SWPadnos_> ok - what's your max_velocity?
[17:38:10] <rayh_ppmc_usc> 72 ipm
[17:38:34] <SWPadnos_> try a g1x10F60, and see if it errors
[17:41:24] <rayh_ppmc_usc> cant x10 that's the soft limit
[17:41:35] <SWPadnos_> how about 9? ;)
[17:43:07] <rayh_ppmc_usc> Yep works fine and will go from + to - 9.999
[17:45:58] <rayh_ppmc_usc> works fine in mdi with g0 x9.999
[17:46:11] <SWPadnos_> now do G1 X0 F70, and see what happens
[17:47:19] <rayh_ppmc_usc> I tried f70 and f72 and they were fine.
[17:47:57] <SWPadnos_> sorry - phone
[17:48:03] <SWPadnos_> what about g0x9?
[17:48:49] <rayh_ppmc_usc> works
[17:48:53] <SWPadnos_> hmm
[17:49:09] <rayh_ppmc_usc> just seems to barf in auto
[17:49:20] <SWPadnos_> I got errors when I did G0, but had no problems with G1 at max feedrate
[17:49:49] <SWPadnos_> and now I can g0 all over the place, and I get no errors
[17:51:39] <SWPadnos_> and I'm running cds a5 300% feed override now - we'll see what happens
[17:51:43] <SWPadnos_> at, not a5
[17:55:57] <SWPadnos_> yep - ran fine at 300%
[17:55:59] <rayh_ppmc_usc> I picked cds.ngc out of a different directory and it seems to be running at 120%
[17:56:11] <SWPadnos_> weird
[17:56:31] <SWPadnos_> and the trouble with 3d_chips is odd too
[17:56:47] <SWPadnos_> I see it plan through line 1005, and no motion
[17:58:10] <rayh_ppmc_usc> I'm hearing dozens of disk reads during the cut of cds.ngc.
[17:58:57] <rayh_ppmc_usc> and I saw all of the "msg, xx" stuff on the terminal before it cut anything.
[17:59:30] <alex_joni> that's odd..
[18:00:15] <rayh_ppmc_usc> Wish I could run mini with it and watch those messaes on the scratch pad.
[18:02:48] <SWPadnos_> phone
[18:03:25] <rayh_ppmc_usc> completed cds,ngc fine from ~/gcode will try again from nc-files
[18:04:25] <rayh_ppmc_usc> following error before motion got home from the endpoint of the program before.
[18:05:00] <alex_joni> try running the program above again
[18:05:03] <alex_joni> to see if that works..
[18:07:03] <rayh_ppmc_usc> is working
[18:07:21] <rayh_ppmc_usc> a diff shows g54,g55 used in the nc-files version.
[18:08:35] <rayh_ppmc_usc> I believe that I did that a while back so that we could offset the program to any place we wanted it.
[18:09:05] <rayh_ppmc_usc> Perhaps what it's saying is that the offset systems are borked in emc2 right now.
[18:09:23] <rayh_ppmc_usc> I'll test for a bit.
[18:12:24] <rayh_ppmc_usc> oh alex, the tkemc editor kicks up an error saying no such file or directory but after you remove that error message it brings up the editor.
[18:12:43] <rayh_ppmc_usc> I suspect a bad directory reference there as well.
[18:13:24] <alex_joni> I guess so :(
[18:13:28] <alex_joni> let me look at that..
[18:14:30] <rayh_ppmc_usc> we've got a broken interpreter or task manager.
[18:14:41] <alex_joni> looking at tkemc it seems ok, but I can't run right now
[18:14:54] <rayh_ppmc_usc> (N50T1M6)
[18:14:54] <rayh_ppmc_usc> (N60M8)
[18:15:12] <rayh_ppmc_usc> fixed 3D_Chips so that it started up.
[18:15:32] <alex_joni> look at http://cvs.sourceforge.net/viewcvs.py/emc/emc/src/emctask/emccanon.cc?rev=
[18:15:47] <alex_joni> maybe that bug cradek fixed isn't fixed in emc2?
[18:18:10] <rayh_ppmc_usc> But those gcode programs ran fine not that long ago.
[18:19:05] <alex_joni> just looked, and the code seems to be there..
[18:20:08] <rayh_ppmc_usc> This is some odd behaviors
[18:21:24] <rayh_ppmc_usc> going to shut down ppmc and start emc.run
[18:23:22] <rayh_ppmc_usc> looks like the following errors are a product of the tuning of ppmc here.
[18:23:56] <rayh_ppmc_usc> at least in part.
[18:24:15] <alex_joni> maybe the PID isn't perfect tuned
[18:24:30] <alex_joni> perfectly
[18:25:38] <rayh_ppmc_usc> Right I found the error message in tcl for the editor.
[18:25:51] <rayh_ppmc_usc> /bin/ls: tcl/scripts: No such file or directory
[18:25:51] <rayh_ppmc_usc> /bin/ls: tcl/scripts: No such file or directory
[18:25:52] <rayh_ppmc_usc> while executing
[18:25:52] <rayh_ppmc_usc> "exec /bin/ls $scriptdir"
[18:25:53] <rayh_ppmc_usc> (procedure "geneditStart" line 99)
[18:25:53] <rayh_ppmc_usc> invoked from within
[18:25:54] <rayh_ppmc_usc> "geneditStart programEditor $programnamestring"
[18:25:56] <rayh_ppmc_usc> (procedure "popupProgramEditor" line 6)
[18:25:58] <rayh_ppmc_usc> invoked from within
[18:26:00] <rayh_ppmc_usc> "popupProgramEditor"
[18:27:50] <alex_joni> hmm.. doesn't sound ok..
[18:29:43] <cradek> what uses exec /bin/ls? That can't be a good idea
[18:29:49] <cradek> ls has different output on different machines
[18:30:07] <alex_joni> tkemc does
[18:30:13] <alex_joni> and it didn't work on doze ;)
[18:30:19] <cradek> big surprise there
[18:30:27] <cradek> * cradek is not a tcl programmer
[18:30:29] <alex_joni> but I found a ls for doze, then it worked
[18:30:40] <cradek> % glob
[18:30:40] <cradek> wrong # args: should be "glob ?switches? name ?name ...?"
[18:30:44] <alex_joni> the problem is $TCLSCRIPTS doesn't get set properly
[18:30:48] <cradek> why not use glob?
[18:30:53] <alex_joni> what's glob ?
[18:31:04] <cradek> expand a shell wildcard
[18:31:15] <alex_joni> if {[info exists env(EMC2_TCL_DIR)]} {
[18:31:15] <alex_joni> set TCLBIN $env(EMC2_TCL_DIR)
[18:31:15] <alex_joni> set TCLSCRIPTS $env(EMC2_TCL_DIR)
[18:31:15] <alex_joni> set TCLBIN $TCLBIN/bin
[18:31:15] <alex_joni> set TCLSCRIPTS $TCLSCRIPTS/scripts
[18:31:15] <alex_joni> }
[18:31:16] <cradek> glob *.nc ==> a.nc b.nc c.nc
[18:31:48] <alex_joni> seems like this doesn't get executed, or EMC2_TCL_DIR holds a strange value
[18:32:57] <alex_joni> rayh: can you run emc.run with verbose output? and tell me what EMC2_TCL_DIR is set to?
[18:33:17] <alex_joni> emc.run -v
[18:36:07] <SWPadnos_> heh - you get funny things when you run a program, then load another one
[18:36:21] <SWPadnos_> (in the AXIS plot window)
[18:37:07] <rayh_ppmc_usc> Got some observations from a pause during a run of chips
[18:37:13] <rayh_ppmc_usc> Motion id 2717 took 0.293959 seconds.
[18:37:13] <rayh_ppmc_usc> Outgoing motion id is 2907.
[18:37:13] <rayh_ppmc_usc> emcTaskPlanRead() returned 0
[18:37:14] <rayh_ppmc_usc> emcTaskPlanLine() returned 3908
[18:37:58] <rayh_ppmc_usc> I see the 200 line look ahead
[18:38:06] <alex_joni> emcTaskPlanLine() should return the line number
[18:38:11] <rayh_ppmc_usc> but I didn't remember the thousand like read ahead.
[18:38:25] <alex_joni> maybe a faster pc now?
[18:38:44] <SWPadnos_> it should be a buffer size thing, not a speed thing
[18:39:25] <alex_joni> probably
[18:41:05] <rayh_ppmc_usc> EMC2_TCL_DIR=/home/rayh/emcdevelop/emc2/tcl
[18:41:28] <alex_joni> sounds ok, then I guess the env doesn't get set properly
[18:41:44] <alex_joni> or doesn't get read properly at the beginning of tkemc.tcl
[18:42:36] <alex_joni> if {[info exists env(EMC2_TCL_DIR)]} {
[18:42:36] <alex_joni> set TCLBIN $env(EMC2_TCL_DIR)
[18:42:36] <alex_joni> set TCLSCRIPTS $env(EMC2_TCL_DIR)
[18:42:36] <alex_joni> set TCLBIN $TCLBIN/bin
[18:42:36] <alex_joni> set TCLSCRIPTS $TCLSCRIPTS/scripts
[18:42:36] <alex_joni> }
[18:42:49] <rayh_ppmc_usc> tkemc sources several tcl files when it begins.
[18:42:52] <alex_joni> after that $TCLSCRIPTS should be /home/rayh/emcdevelop/emc2/tcl/scripts
[18:43:06] <alex_joni> this is just at the top (first few lines, 10 or so)
[18:45:11] <rayh_ppmc_usc> I don't see any $TCLSCRIPTS
[18:45:49] <rayh_ppmc_usc> want me to post the whole list of these?
[18:45:55] <alex_joni> not in emc.run
[18:46:03] <alex_joni> $TCLSCRIPTS is only in tkemc
[18:47:33] <rayh_ppmc_usc> oh. okay and it should be $EMC2_TCL_DIR/scripts
[18:47:43] <alex_joni> right, but absolute path
[18:48:24] <alex_joni> should be /home/rayh/emcdevelop/emc2/tcl/scripts
[18:49:27] <rayh_ppmc_usc> set TCLBIN tcl/bin
[18:49:27] <rayh_ppmc_usc> set TCLSCRIPTS tcl/scripts
[18:49:46] <alex_joni> that's before that, and that should get overriden a bit further down
[18:50:23] <alex_joni> you do have the latest tkemc.tcl I hope
[18:50:50] <alex_joni> 1.11 it reads here (taken from CVS/Entries)
[18:51:43] <rayh_ppmc_usc> Starting EMC DISPLAY program: tkemc
[18:51:48] <rayh_ppmc_usc> /home/rayh/emcdevelop/emc2/tcl/scripts
[18:52:00] <rayh_ppmc_usc> I added a puts and that is the result.
[18:52:03] <alex_joni> seems OK to me ;)
[18:52:37] <alex_joni> now where is it failing?
[18:52:56] <alex_joni> ahhh.. figured it out
[18:53:07] <alex_joni> the problem is in genedit.tcl
[18:53:12] <alex_joni> didn't read that properly :(
[18:53:19] <rayh_ppmc_usc> Right.
[18:53:38] <rayh_ppmc_usc> Those were written to be either stand alone or sourced buy tkemc
[18:53:40] <alex_joni> set scriptdir tcl/scripts
[18:53:40] <alex_joni> set files [exec /bin/ls $scriptdir]
[18:53:52] <alex_joni> inside genedit.tcl
[18:54:06] <alex_joni> that needs to receive the same treatment as tkemc did
[18:54:56] <alex_joni> but how it is now is pretty borked, because it assumes emc gets always run from emc2/
[18:55:11] <alex_joni> can't go to scripts/ and run 'emc.run'
[18:55:21] <alex_joni> because then it would be ../tcl/scripts
[18:55:47] <alex_joni> also.. if you just go to tcl/bin and run genedit.tcl it will fail with the same reason
[18:59:21] <rayh_ppmc_usc> phone
[19:18:00] <rayh_ppmc_usc> So how do we handle this.
[19:18:18] <alex_joni> handling this to run from tkemc is easy
[19:18:29] <alex_joni> handling it to run by itself is harder
[19:18:40] <alex_joni> to properly run by itself I mean
[19:19:13] <alex_joni> if you do bin/genedit.tcl it will work, but going to bin/ and running genedit.tcl won't
[19:19:29] <alex_joni> hang on, booting a BDI and commiting some changes. ok?
[19:29:16] <alex_joni> ok.. back
[19:29:21] <alex_joni> rayh: still around?
[19:29:23] <rayh_ppmc_usc> quickest fix is to remove the menu item entirely.
[19:29:40] <alex_joni> nah.. that's not nice
[19:29:41] <rayh_ppmc_usc> Right. the quick fix is to check for the existence of the dir before that menu item is setup
[19:29:45] <alex_joni> hang on, cvs up here
[19:33:28] <alex_joni> darn gotta rebuild to test ;)
[19:33:38] <alex_joni> emc2 was outdated on this machine
[19:37:56] <rayh> I don't really think that many folk use the scripting ability here so the easiest is to remove entirely.
[19:39:07] <alex_joni> I'm looking at it now, should work I think
[19:40:33] <alex_joni> how do I test if the variable $TCLSCRIPTS exists?
[19:40:37] <alex_joni> or has been set?
[19:41:25] <rayh> a newline with puts $TCLSCRIPTS <enter>
[19:41:28] <rayh> should do it.
[19:41:43] <alex_joni> no I mean during program execution
[19:41:55] <alex_joni> if (exists $TCLSCRIPTS) then foo
[19:44:44] <alex_joni> how do you run genedit.tcl by itself?
[19:45:18] <rayh> just ./genedit.tcl
[19:45:20] <SWPadnos_> hm - something's screwy - brb
[19:45:38] <alex_joni> genedit.tcl has only functions defined in it
[19:47:09] <rayh> phone
[19:58:03] <alex_joni> seems most of the tcl scripts and bins have been blindly copied from emc1
[19:58:07] <alex_joni> and most don't even work
[19:58:40] <alex_joni> some do work sourced from tkemc.tcl , but that's it
[20:02:31] <rayh_ppmc_usc> Right there was no effort to emc2ify the tickle stuff.
[20:02:53] <rayh_ppmc_usc> I don't even know who moved it and why it was setup the way it was.
[20:04:10] <alex_joni> heh.. we can find out who, not really why ;)
[20:04:30] <alex_joni> I made some changes to the bin/ tcl stuff
[20:04:49] <alex_joni> I mean tcl/bin/ stuff
[20:05:53] <rayh_ppmc_usc> The executable tcl used to be moved by make from emc/src/emctask and emcio
[20:06:26] <rayh_ppmc_usc> into emc/plat/nonrealtime/bin with all the other user space executable stuff
[20:06:27] <alex_joni> and changed in the process
[20:06:44] <alex_joni> ok.. commited
[20:06:48] <alex_joni> can you look at that?
[20:06:49] <rayh_ppmc_usc> Yes. some filenames wer changed
[20:07:21] <rayh_ppmc_usc> k
[20:07:24] <alex_joni> and some internal stuff was replaced (UNKNOWNPLAT replaced with the nonrealtime PLAT name)
[20:08:17] <SWPadnos_> logger_devel: bookmark
[20:08:17] <SWPadnos_> See http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2005-12-01#T20-08-17
[20:08:17] <rayh_ppmc_usc> exactly
[20:08:50] <rayh_ppmc_usc> Then soon after that we started using a generic naming convention plat/nonrealtime/bin
[20:09:08] <rayh_ppmc_usc> but all of that got lost with the emc2 file structure.
[20:09:49] <alex_joni> yup
[20:09:52] <SWPadnos_> plus the fact that emc2 wasn't (until recently) installed
[20:10:00] <SWPadnos_> just run from the make dir
[20:10:02] <rayh_ppmc_usc> And I can fuss and throw things all I want but it isn't going to fix the emc2 file structure so I guess it'll be easier to fix the tcl
[20:10:08] <alex_joni> SWPadnos_: that adds some complexity to it
[20:10:24] <SWPadnos_> yep
[20:10:45] <alex_joni> but it's coming along, I'd say ;)
[20:10:58] <SWPadnos_> I wouldn't know - I just run from the cvs dir ;)
[20:11:09] <SWPadnos_> well - the sandbox anyway
[20:11:13] <alex_joni> that is living proof ;)
[20:11:20] <rayh_ppmc_usc> you know when cvs patches my files it puts garbage in <<<<<<<
[20:11:23] <alex_joni> it uses the same hooks as the installed version
[20:11:36] <alex_joni> rayh_ppmc_usc: that means you had a local change
[20:11:42] <alex_joni> and it got conflicts during merge
[20:11:48] <SWPadnos_> there's an option for diff and / or xxdiff to show those changes correctly
[20:11:50] <rayh_ppmc_usc> okay
[20:11:53] <SWPadnos_> (I dont know it though)
[20:12:24] <alex_joni> IF you want to scrap your changes you can either delete the file, and cvs up, or cvs up -C (that brings the files from CVS, without caring of anything you changed)
[20:13:24] <SWPadnos_> thanks - I was wondering what option would do that (I had been renaming or deleting)
[20:13:49] <alex_joni> I usually do my thing, then decide it's crap and do 'cvs up -dPC' to scrap it all
[20:14:17] <SWPadnos_> heh - that's almost as good as M101 being rm -rf /
[20:15:52] <SWPadnos_> so - I had an odd problem - one CPU was pegged at 100% utiilzation, but top showed nothing using more than about 10%
[20:15:53] <alex_joni> darn.. that's crap ;) hang on
[20:16:03] <SWPadnos_> any idea how to find the offending process?
[20:16:29] <alex_joni> killall *
[20:16:47] <SWPadnos_> well - that might kill it, but it wouldn't exactly find it for me ;)
[20:17:04] <rayh_ppmc_usc> looks like the edit script starts as soon as emc does
[20:17:18] <alex_joni> yeah, already noticed that
[20:17:21] <alex_joni> fixing it now
[20:18:28] <alex_joni> heh.. I just ran emc like this:
[20:18:29] <alex_joni> juve@centrino:~/emc/emc2/tcl$ sudo ../scripts/emc.run ../configs/stepper/emc.ini
[20:18:54] <alex_joni> rayh: does that suit your needs? of having stuff in a separate dir?
[20:19:34] <rayh_ppmc_usc> I'm lost
[20:20:05] <alex_joni> well.. I took the stepper related config files and put them in a dir called configs/stepper/
[20:20:24] <alex_joni> and tried to run it, and it ran ;) without having to change anything
[20:20:29] <rayh_ppmc_usc> I see that the only thing I'm lost with is the need for the massive run line.
[20:20:43] <alex_joni> that will need some changes ;)
[20:20:44] <rayh_ppmc_usc> I'd a whole lot rather emc stepper
[20:20:58] <alex_joni> yes... just wanted to see if the rest of the system works
[20:21:02] <alex_joni> I'll get there
[20:21:21] <rayh_ppmc_usc> Good. I found that worked here as long as I did the references in the ini file correctly.
[20:21:27] <alex_joni> please update, genedit shouldn't cause any more problems
[20:21:37] <rayh_ppmc_usc> okay.
[20:21:41] <alex_joni> there should be no references in the ini file
[20:21:49] <alex_joni> ini files should assume same dir
[20:22:08] <alex_joni> NML_FILE = emc.nml
[20:22:31] <alex_joni> NOT ../emc.nml, NOT configs/emc.nml, NOT foo/emc.nml, just emc.nml
[20:22:32] <rayh_ppmc_usc> wow cvs up -C does make a difference
[20:22:39] <SWPadnos_> hmm - maybe make emc[,run] take a name without .ini as a subdir of the config directory, and [name].ini as an ini file in the config dir
[20:22:55] <alex_joni> SWPadnos_: did you see my feature request ?
[20:23:08] <SWPadnos_> yes, but I didn't read it ;)
[20:23:12] <alex_joni> read it
[20:24:09] <SWPadnos_> actually - I had read it, but it doesn't say anything about the mechanism, only that you want config file dirs
[20:24:12] <SWPadnos_> and I agree
[20:24:47] <SWPadnos_> I'm suggesting that 'emc stepper' would look for files in configs/stepper/, and find the emc.ini and whatever else from there (or relative to there, so ../core_servo.hal would work)
[20:25:03] <SWPadnos_> but emc stepper.ini looks in configs/ for stepper.ini (as it is now)
[20:25:03] <alex_joni> yeah.. I said that.. forgot to add it to the tracker :(
[20:25:07] <SWPadnos_> hhe
[20:25:10] <SWPadnos_> heh
[20:25:30] <alex_joni> emc stepper, should look for:
[20:25:35] <alex_joni> 1. configs/stepper.ini
[20:25:42] <SWPadnos_> the other possibility would be for stepper/ to specify the directory, and that's probably easier and more robust, but looks funny for a newB
[20:25:43] <alex_joni> 2. configs/stepper/stepper.ini
[20:25:49] <alex_joni> 3. configs/stepper/emc.ini
[20:25:57] <SWPadnos_> yep
[20:26:02] <alex_joni> or maybe configs/stepper/default.ini
[20:26:25] <alex_joni> I'll do all 4 variants
[20:26:26] <SWPadnos_> yeah - I'm thinking that emc.ini (or whatever) should be before stepper.ini
[20:26:37] <alex_joni> doesn't matter..
[20:26:39] <SWPadnos_> so you copy sample/ to mystuff/
[20:26:49] <alex_joni> I see...
[20:26:50] <SWPadnos_> and don't have to rename anything
[20:27:03] <alex_joni> but then you can't cvs up
[20:27:30] <SWPadnos_> anything in cvs would update, anything you make locally isn't part of cvs anyway (unless you add it)
[20:27:54] <alex_joni> right..
[20:28:06] <SWPadnos_> sample/ wouldn't have core_* though - those would be in the sample/../ dir ;)
[20:28:27] <alex_joni> right.. I think all .hal files might be in a different dir?
[20:28:41] <SWPadnos_> no - I'd have them in with the configs
[20:28:54] <rayh_ppmc_usc> euuuuu now the system seems to remember which coord system you were using when you shut down.
[20:28:55] <SWPadnos_> but sample/ would have .ini and .hal files for that config
[20:29:09] <alex_joni> lets take mazak as an example
[20:29:10] <SWPadnos_> it should always have done that - it's in the spec
[20:29:37] <SWPadnos_> oh - for the mazak you'll have .clp as well ;)
[20:30:30] <alex_joni> is it just me, or there isn't a mazak.nml in there?
[20:30:43] <SWPadnos_> should there be?
[20:30:52] <rayh_ppmc_usc> I don't think it was ever committed.
[20:31:12] <rayh_ppmc_usc> but since it's the same as emc.nml it should have been changed in the ini
[20:31:39] <SWPadnos_> out of curiosity, what would have required a different NML file for the Mazak?
[20:32:01] <rayh_ppmc_usc> a remote terminal running tkemc or axis
[20:32:16] <SWPadnos_> ok - so it's just the usage, not the machine
[20:32:26] <SWPadnos_> (that's why I was wondering)
[20:32:42] <alex_joni> yes..
[20:32:53] <rayh_ppmc_usc> don't know quite what you mean by not machine
[20:32:59] <alex_joni> it's not changed, it has mazak.nml in there
[20:33:14] <alex_joni> rayh_ppmc_usc: he thought it's machine specific, and it's not
[20:33:22] <alex_joni> machine = PC
[20:33:31] <SWPadnos_> in other words, it's not the hardware of the mazak, or what you have connected to it, that would need changes to the NML file
[20:33:40] <rayh_ppmc_usc> It could be. It would certainly be integration specific
[20:33:45] <SWPadnos_> it's where you want to run the UI(s)
[20:33:46] <alex_joni> no.. just the way you run the components
[20:33:59] <alex_joni> if you run all emc components on one PC, then emc.nml is OK
[20:34:16] <alex_joni> if you run task on one PC, IO on another, GUI on another, etc.. then you need another nml
[20:34:27] <SWPadnos_> I understand - Paul and I had multiple UIs on our machines, running emc on each other's machines, at Fest
[20:34:34] <rayh_ppmc_usc> Well I think that answer requires a larger look at NML cause you could have the IO running on another pc as well
[20:34:58] <SWPadnos_> sure - that's what I was wondering - whether you guys ended up using multiple PCs on the Mazak
[20:35:11] <alex_joni> no, just one afaik
[20:35:12] <rayh_ppmc_usc> No we didn't
[20:36:04] <rayh_ppmc_usc> I spoke with WillS at NIST the other day and asked if the Java code for NML changes still worked.
[20:36:38] <alex_joni> does for me
[20:36:44] <rayh_ppmc_usc> He hit a few keystrokes to add an second set of io channels and answered yep.
[20:37:03] <SWPadnos_> heh - maybe my new computer is fast enough to use that ;)
[20:37:41] <rayh_ppmc_usc> I tried to download java.sun for linux but it borked during the transfer.
[20:38:27] <rayh_ppmc_usc> We ought to take another look at all the NML work that alex and paul did a while back.
[20:39:06] <rayh_ppmc_usc> as soon as we get past the emc2 head as the place to work.
[20:39:24] <alex_joni> it's in a branch on emc2
[20:39:37] <alex_joni> but not much done, we mainly classified all the NML messages
[20:39:50] <alex_joni> with how they are called, where they are sent from, where received
[20:39:55] <alex_joni> stuff like that
[20:40:08] <rayh_ppmc_usc> that is the starting point.
[20:40:47] <alex_joni> cradek: you still around chris?
[20:40:50] <rayh_ppmc_usc> I see that only one tkemc --> script works
[20:41:06] <cradek> umm, no
[20:41:14] <cradek> not if you're going to ask me about tcl
[20:41:18] <alex_joni> you had a good idea for emc.run
[20:41:26] <alex_joni> something involving getopts ;)
[20:41:49] <cradek> well I wanted it to handle command line arguments in a standard way
[20:41:57] <cradek> so getopt is the simple way to do it
[20:42:32] <alex_joni> is there a simple(standard) way to do the 4 ways I described above?
[20:42:58] <alex_joni> or should I just test for them..?
[20:43:35] <cradek> you will have to test
[20:43:45] <alex_joni> ok.. I'm doing it now
[20:43:49] <cradek> that is not a problem of parsing command line arguments
[20:44:04] <cradek> why do you want it to do these magic things instead of just letting the user specify the file he wants to specify?
[20:44:28] <cradek> emc -i any/path/to/an/ini/file.ini
[20:44:29] <alex_joni> so aunt tillie can do: emc stepper
[20:44:48] <alex_joni> or emc servo ;)
[20:44:53] <cradek> aunt tillie can use a symlink if s?he wants to do that
[20:45:06] <alex_joni> no she can't ;) she doesn't know how
[20:45:42] <cradek> well whoever set up her machine will do it then
[20:45:46] <alex_joni> don't see anything wrong in testing.. besides bloating the file a bit
[20:45:57] <alex_joni> she does a BDI ;) pretty simple
[20:46:03] <cradek> but magic behavior is always bad
[20:46:24] <cradek> what if I have both configs/stepper.ini and configs/stepper/stepper.ini?
[20:46:39] <cradek> aunt tillie will be mad because it doesn't guess right what she wants
[20:46:45] <alex_joni> it will use the first one, if you specify stepper
[20:46:59] <cradek> aunt tillie will be mad because it doesn't guess right that she wants the second one
[20:47:05] <alex_joni> lol :)
[20:47:11] <cradek> I'm not kidding
[20:47:12] <alex_joni> yes.. get your point
[20:47:22] <cradek> don't make the stuff magic when you can make it precise (and exactly like the rest of unix)
[20:49:35] <cradek> if you use getopt and parse cmd line arguments in a standard way, there can be a clear and precise thing printed when you type emc -?
[20:49:52] <alex_joni> I see
[20:50:08] <cradek> [-i inifile] = specify ini file
[20:50:53] <cradek> otherwise it will take several sentences to explain the behavior and it might still be unpredictable
[20:51:21] <cradek> and I can have my_inis/experimental/blue_machines/machine_1/testing.ini if I want
[20:52:00] <alex_joni> not as it was..
[20:52:13] <cradek> but you're fixing it :-)
[20:52:15] <alex_joni> I'm working towards that
[20:52:32] <alex_joni> how about files referenced from the ini?
[20:52:43] <alex_joni> say I have configs/step_cl/step_cl.ini
[20:52:50] <alex_joni> which references core_stepper.hal
[20:53:01] <alex_joni> so does configs/stepper/stepper.ini
[20:53:16] <alex_joni> I wouldn't want core_stepper.hal to be in 2 places in HAL
[20:53:37] <alex_joni> would it be bad to look under the current dir, and if not found to look under configs/ and only then fail if not found?
[20:53:52] <cradek> that seems reasonable
[20:53:59] <cradek> that's what cpp does
[20:54:05] <rayh_ppmc_usc> I'm rapidly comming to the conclusion that there is no such thing as core_stepper or servo
[20:54:16] <alex_joni> how so?
[20:54:29] <rayh_ppmc_usc> Was just on the phone with a fellow who is running m5i20
[20:54:56] <rayh_ppmc_usc> He wrote up some stuff hal and such for it.
[20:55:05] <alex_joni> and?
[20:55:27] <rayh_ppmc_usc> but now he can't run it because core_servo changed
[20:56:06] <alex_joni> how so?
[20:56:57] <rayh_ppmc_usc> Now instead of assigning values to the tuning parameters it's trying to look them up in the ini
[20:57:38] <SWPadnos_> where they aren't, by default
[20:57:56] <rayh_ppmc_usc> you got it.
[20:58:27] <rayh_ppmc_usc> This thing gets messy in a hurry.
[20:58:52] <SWPadnos_> btw - as for 'emc stepper' changing meanings - that's why I was thinking that "stepper" would mean "use the stepper dir", and "stepper.ini" means use stepper.ini
[20:58:56] <rayh_ppmc_usc> tiny changes to the names of hal pins can totally trash a system
[20:59:22] <SWPadnos_> yep - HAL is great from a configuration standpoint, but not from a naming standpoint
[21:00:09] <rayh_ppmc_usc> We really need a way to flag all the files using ppmc.x.what-ever
[21:00:09] <alex_joni> SWPadnos_: as cradek said, that easily gets confusing
[21:00:10] <SWPadnos_> it would make more sense to me if (for example) the ppmc driver would just give you ppmc.dout.<n> for the digital outputs
[21:00:28] <alex_joni> not if you are running 4 boards..
[21:00:41] <SWPadnos_> if you have two boards, you get ppmc.dout<0-31>
[21:01:09] <SWPadnos_> yes - since you have to manually configure which board is first in the address space anyway
[21:02:17] <SWPadnos_> in fact, it would be more of an *abstraction* layer, if all the drivers would just add some dout.<n> pins, and leave the <drivername>.<instance> off the name entirely
[21:02:25] <rayh_ppmc_usc> You know what I think is missing. Way back when I compared hal to lego blocks I was thinking of whole blocks being plugged together
[21:02:41] <SWPadnos_> rather than individual bits and pieces
[21:02:52] <rayh_ppmc_usc> yep.
[21:03:06] <rayh_ppmc_usc> what we need is a linkb
[21:03:23] <rayh_ppmc_usc> that simply takes all of iocontrol and plugs it into classicladder
[21:03:29] <rayh_ppmc_usc> 1 for 1
[21:03:32] <SWPadnos_> heh - that works great if the modules have identical needs and names
[21:04:02] <rayh_ppmc_usc> i know there would be issues with bit, int, float
[21:04:18] <SWPadnos_> but what to do about things like "enable", that need to be plugged into a lot of things
[21:04:53] <rayh_ppmc_usc> In the cl example you would do that with a rung.
[21:05:08] <SWPadnos_> types aren't a problem, and in fact, there can be a macro that goes through all output pins on one module, and tries to connect to all identically named input pins (of the same type) on another module
[21:05:32] <SWPadnos_> but is it an error when you can't connect all of them?
[21:05:40] <SWPadnos_> or if they aren't of matching type?
[21:06:05] <rayh_ppmc_usc> The alternative is to make a graphical front end to hal configuration files.
[21:06:09] <SWPadnos_> yep
[21:06:27] <SWPadnos_> there's a concept in LabView, called a "bundle" - that would be a good thing here
[21:06:30] <rayh_ppmc_usc> and allow the low level man readable
[21:06:49] <rayh_ppmc_usc> Like a 50 pin ribbon?
[21:07:35] <SWPadnos_> kind of ;)
[21:08:02] <SWPadnos_> more like "a bit, a byte, and 2 floats", taken as a package
[21:08:12] <SWPadnos_> connect the bundle to something, and all the sub-parts get connected
[21:08:17] <SWPadnos_> like a pin struct
[21:08:30] <SWPadnos_> (i mean, a struct of many pins)
[21:09:18] <rayh_ppmc_usc> okay. I wasn't thinking of the nature of the signal carried on the ribbon
[21:09:27] <rayh_ppmc_usc> I can see what you are saying
[21:10:22] <SWPadnos_> so - you can group all the spindle outputs (from iocontrol) together, and connect them to classicladder (for example)
[21:10:29] <rayh_ppmc_usc> I could speed up modeling this in tickle if i could bin/halcmd list owner.
[21:10:39] <SWPadnos_> yes - I know ;)
[21:11:15] <alex_joni> hrmm.. seems the stuff with subdirs works if all the files are in that subdir
[21:11:18] <SWPadnos_> jmk was planning some structural change to halcmd, else I would have made "show" print the owner name rather than the ID number
[21:11:34] <rayh_ppmc_usc> I tried writing hal files by listing all the parport then all the cl and it made a mess.
[21:11:39] <alex_joni> because some components, scan the ini for the nml file aswell
[21:12:29] <rayh_ppmc_usc> I think the more logical way is to follow each signal from start to finish.
[21:13:06] <SWPadnos_> doesn't show sig do that for you?
[21:13:14] <SWPadnos_> other than the missing owner names ;)
[21:13:15] <rayh_ppmc_usc> then when you interpose CL that muddies things
[21:13:28] <rayh_ppmc_usc> Show sig is a bitch to read
[21:15:11] <rayh_ppmc_usc> phone
[21:15:17] <SWPadnos_> me too
[21:19:46] <SWPadnos_> gotta run for a bit - be back in a couple of hours
[21:19:50] <SWPadnos_> SWPadnos_ is now known as SWP_Away
[23:36:41] <alex_joni> night
[23:57:57] <jmkasunich> hey cradek, you here?