Back
[02:02:21] <cradek> KimK: can we see the hal file too please?
[02:34:07] <cradek> well in a half hour's study I don't see the problem
[02:53:24] <SWPadnos> what's strange is that there was no error about no boards being found
[02:54:04] <SWPadnos> so there's a board (or at least boards != 0 at line 632), but it's not detected as a USC/UPC at bus 0 ID 0
[02:54:49] <SWPadnos> there are other "clerical" errors in the driver as well
[02:55:12] <SWPadnos> (this is somewhat intended as notes for myself, once I'm at a machine I can edit/test with)
[02:56:03] <SWPadnos> 1) the extra_dac/extra_dio arrays shouldn't have 24 entries, since that depends on MAX_BUS being 3
[02:58:01] <cradek> is 3 the MAX MAX_BUS setting?
[02:58:04] <SWPadnos> 2) in the extra{dio,dac} check around lines 665-678, the bus and board numbers will be incorrect if they are > 0. This is due to the fact that there are only 8 * MAX_BUS entries, but the print does N>>4 and N&0x0F to extract the bus and board #s
[02:58:10] <SWPadnos> I don't think so
[02:58:49] <SWPadnos> at least I don't think there's any reason the code can't support more than 3 buses, it just seems like it may be unnecessary
[02:59:00] <cradek> so do you see the actual problem? I wasn't able to decipher how the bus/port stuff works really at all
[02:59:22] <cradek> (I bet we really need to see Kim's loadrt command)
[02:59:24] <SWPadnos> I don't think I see the actual problem, just noting the things I can see :)
[02:59:32] <SWPadnos> yes, that's pretty critical
[03:00:09] <cradek> I couldn't even figure out how to (easily) tell him to change the rtapi log level. it would give us more information from the common parport code. do you know how to do that?
[03:00:52] <SWPadnos> hmmm. do you have to edit the emc script to do some echo into /proc/rtapi/<something>?
[03:01:07] <cradek> I didn't immediately see anything there
[03:01:52] <SWPadnos> but the level is saved and restored in the PPMC driver, and I only noticed the restore
[03:02:23] <SWPadnos> oh no, that's commented out (line 405)
[03:02:27] <SWPadnos> according to gitweb
[03:11:21] <SWPadnos> oh hmmm
[03:11:38] <SWPadnos> yes, we need to see the loadrt line
[04:09:22] <SWPadnos> ok, I was wrong about 2) above - it's not the loop/index variable that's printed, it's the array element (duh)
[04:12:28] <SWPadnos> about the only failure mode I can see that would print those lines to dmesg is if the board ID is misread, so the board looks like neither a USC nor a UPC
[04:22:24] <KimK> cradek, SWPadnos: Hi, I'm back, thanks for all your hard study. Yes, I will go paste the loadrt line right away, and pastebin ini, hal, etc.
[04:22:37] <SWPadnos> oh, just in time :)
[04:30:15] <BridgeportIIa> OK, here's ini
http://pastebin.ca/1875809 and here's hal
http://pastebin.ca/1875810. I'll look around and see if there's anything else that looks like you might need it.
[04:30:39] <SWPadnos> that should be plenty for tonight :)
[04:31:28] <SWPadnos> what are the changes between the 2.3.5 config that works and the 2.4.x one that doesn't?
[04:31:41] <SWPadnos> maybe a diff would be good (diff -u)
[04:33:07] <BridgeportIIa> The only thing I was doing was swapping old and new copies of the tool table, and blocking/unblocking the nml line (not sure how much that's needed in my case, but I was doing it anyway).
[04:33:25] <SWPadnos> ok, if there were no other changes that's cool
[04:35:15] <BridgeportIIa> And as I scan through I notice one typo in my comments, where I said "you can't say L-A-T-H-E=1" it should read "you can't say L-A-T-H-E=0". I tried to add LATHE=0 (because this is a mill) and discovered it was trying to be a lathe anyway. Hence I had to "spell it" so the ini file wouldn't "hear me", lol.
[04:38:26] <BridgeportIIa> In Jon's originally supplied example configs he had a bunch of separate files which made me crazy after a while and I put them all in one. Sorry if that is not how you're used to seeing them.
[04:40:10] <SWPadnos> no worries
[04:42:12] <BridgeportIIa> OK, you might also want univstep_postgui.hal at
http://www.pastebin.ca/1875817
[04:42:26] <SWPadnos> ok, thanks
[04:42:44] <SWPadnos> I wish I knew how to set the RTAPI message level so we could see more output in dmesg
[04:43:18] <SWPadnos> I can only see one way that you can get the messages from your last post, and that's if the board is recognized as something it isn't
[04:43:32] <SWPadnos> which could be from a bus error
[04:43:49] <SWPadnos> you might try specifying the port with port_addr=0x378 or similar
[04:48:05] <BridgeportIIa> OK, would this be where it now says:
[04:48:05] <BridgeportIIa> # load parallel port (#2) component
[04:48:05] <BridgeportIIa> loadrt hal_parport cfg="0xdcf8 in"
[04:52:14] <SWPadnos> no, on the ppmc loadrt line
[04:52:49] <SWPadnos> of course, you should use the actual address of the port the USC is connected to
[04:56:39] <BridgeportIIa> So then, maybe something like: loadrt hal_ppmc port_addr=0x378 extradac=0x00 ? Yikes, is that stuff documented anywhere?
[04:56:58] <BridgeportIIa> I'll look...
[04:57:58] <SWPadnos> http://www.linuxcnc.org/docs/2.4/html/drivers_pico_ppmc.html
[04:58:03] <BridgeportIIa> OK, I see it in the Integrator's Manual
[04:58:11] <BridgeportIIa> Oh, Ok, another one, thanks
[04:58:32] <BridgeportIIa> More than one way to skin the proverbial cat
[04:58:36] <SWPadnos> the one I linked to doesn't mention extra_dac or extra_dio though :)
[05:01:24] <BridgeportIIa> Neither does mine (stock installed docs). It does say default is 0x0378. But you suspect it may be not taking, or getting lost, or something, and is better specified? OK, no problem.
[05:02:00] <SWPadnos> hmmm
[05:02:27] <SWPadnos> ok, so this will turn on loads of RTAPI debugging: "echo 5 >/proc/rtapi/debug"
[05:02:35] <SWPadnos> but it has to be done within the emc script
[05:03:01] <SWPadnos> (since it needs to be done after RTAPI is loaded but before the hal_ppmc driver loads)
[05:04:34] <BridgeportIIa> I'm not completely sure what the emc script is (I can guess), or where it is, or how to alter it.
[05:04:59] <SWPadnos> if you want to get the rtapi messages, you can look in the emc script, and add that line (without the quotes) somewhere just before the line "# 4.3.3 export the location ... (blah blah blah)"
[05:05:05] <SWPadnos> which emc will tell you where it is
[05:05:10] <BridgeportIIa> OK
[05:05:20] <SWPadnos> and you can even do sudo nano -w `which emc`
[05:12:24] <BridgeportIIa> Sorry, I don't know nano. I tried gksudo gedit `which emc' instead and still got a carat prompt. (?)
[05:13:46] <SWPadnos> well, you can always just use which to find it and then type or paste the name
[05:14:00] <SWPadnos> both quotes are supposed to be backquotes, FWIW
[05:14:12] <SWPadnos> (they showed up as front and back here)
[05:14:29] <SWPadnos> or backquote and apostrophe
[05:16:21] <BridgeportIIa> OK thanks. But there must be more wrong. which emc returns /usr/bin/emc. So far so good. Except cd /usr/bin/emc says (long story short) emc isn't a directory. But it looks like it when I cd to /usr/bin/ Is that emc a link to some other directory? This is strange.
[05:16:50] <SWPadnos> emc is a script in /usr/bin
[05:16:56] <SWPadnos> it's executable, so you can run it
[05:17:12] <BridgeportIIa> Oh, OK, that's why it looks odd.
[05:17:33] <SWPadnos> yes, green if you have the default terminal and ls color scheme
[05:18:41] <BridgeportIIa> OK, I finally got it open, sorry for the bother
[05:22:41] <SWPadnos> no worries
[05:22:48] <SWPadnos> but soon I will be asleep :)
[05:23:21] <SWPadnos> if you can try running 2.4.1 and pastebin the output of dmesg, I'll take a quick look
[05:23:27] <SWPadnos> (soon! :) )
[05:25:23] <BridgeportIIa> OK, try this:
http://www.pastebin.ca/1875829
[05:26:37] <SWPadnos> ok, there's definitely a problem. you'll have to stick with 2.3.x for a bit
[05:27:00] <SWPadnos> the ppmc driver is detecting a PPMC DAC card at every possible address on that bus
[05:27:29] <SWPadnos> which probably means that there's a problem with data transfer from the USC on that port
[05:27:59] <SWPadnos> you could try swapping the two ports around (swap the addresses between the ppmc and parport drivers, and of course the cables)
[05:28:28] <BridgeportIIa> OK, no problem, I expected to roll back, machine is needed in morning again. I only have one parallel port though.
[05:29:08] <SWPadnos> oh, OK. you had mentioned a parallel port line when I suggested adding the port to the loadrt line, I thought it was from your config
[05:29:09] <BridgeportIIa> One parallel port, one Universal Stepper Controller.
[05:29:11] <SWPadnos> (but didn't look for it)
[05:29:57] <BridgeportIIa> No problem, I appreciate all you guy's hard work. Get some sleep, we'll talk of this more later. Thanks again.
[05:30:05] <SWPadnos> and don't forget to change the emc script back :)
[05:30:09] <SWPadnos> sure. night
[05:30:49] <BridgeportIIa> goodnight
[06:39:11] <alex_joni> SWPadnos: easier to edit /etc/emc2/rtapi.conf
[06:39:19] <alex_joni> there's a DEBUG='1' in there, just up it to 5
[06:39:22] <alex_joni> cradek: ^^
[06:39:44] <alex_joni> that just increases DEBUG level on realtime start, so no need to mess with the emc2 runscript
[06:51:50] <alex_joni> SWPadnos: somehow I doubt that card has 64 DACs on it.. right?
[08:28:08] <alex_joni> micges_work: hi
[08:39:55] <micges_work> hi
[08:51:06] <alex_joni> now that 2.4.x is out, thikn we should get back on track of ja3?
[08:53:59] <micges_work> yes
[08:54:22] <micges_work> soon I'll have gantry servo for tests (long time tests)
[09:14:17] <alex_joni> cool
[09:18:25] <micges_work> issy from bulgaria reported some weird problem with gantry servo on ja3, maybe can I reproduce
[09:18:56] <micges_work> sadly gantry axis was unable to use, he maked hal fix for this
[10:21:45] <jthornton> when a variable is set to true should any of the following be acceptable in HAL true, True, TRUE, 1 ?
[11:13:11] <jthornton> crumb make: *** [../docs/src/Master_User.pdf] Error 1 :/
[11:17:32] <jthornton> ah ha the nurbs strikes again
[11:24:19] <CIA-2> EMC: 03jthornton 07v2.4_branch * r324bf1fce995 10/docs/src/hal/pyvcp.lyx: seems like true doesn't work while True does
[12:05:25] <jepler> I looked back at bridgeportIIa's trouble and the other thing I would have suggested was disabling the linux parport driver to see if that made a difference. We know it doesn't detect EPP but is it putting the port in some mode where EPP in fact does not work?
[12:07:31] <jepler> his board should be a USC, right? 0x4y
[12:09:47] <Jymmm> jepler: Doesn't the parport driver poll the port for it's current status/configuration?
[12:10:48] <jepler> Jymmm: yes, in 2.4 emc coexists with the linux parport driver and in the case of epp boards (pico, mesa, pluto) it checks that linux detected epp mode
[12:11:26] <jepler> Jymmm: in 2.4.0 it was a fatal error if the driver wanted epp but linux didn't detect it. A user quickly reported that his system (also, coincidentally, pico) didn't work with 2.4.0 because Linux didn't detect an EPP-capable port.
[12:11:51] <Jymmm> Ah, ok.
[12:12:02] <jepler> In his case the problem was fixed by disabling the Linux parport driver in which case emc goes ahead and directly uses a port at a given address without checking anything
[12:12:42] <jepler> so in 2.4.1 I made the failure to detect EPP a non-fatal error, but now a second user with pico is having trouble and he is getting the non-fatal message that indicates Linux didn't detect EPP support too
[12:12:46] <jepler> #
[12:12:46] <jepler> [ 3864.049053] PARPORT: continuing anyway.
[12:12:49] <jepler> [ 3864.049051] PARPORT: linux parport parport0 does not support mode 4.
[12:12:52] <jepler> #
[12:14:00] <jepler> all of my (two) test systems worked OK for both pluto and mesa with the new scheme, but I had no pico to test and obviously two machines is not a huge sample anyway
[12:15:19] <Jymmm> WHAT?! You dont have 100,000 systems to beta test on behind you?
[12:15:37] <alex_joni> Jymmm: he's still waiting on your shipment
[12:15:47] <jepler> it's unfortunate if this scheme doesn't work for the vast majority of systems, because where it works it's superior to the "use an address and hope" system.
[12:15:54] <jepler> bbl, time to head to the office
[12:16:10] <Jymmm> alex_joni: Hey, my shipment went to the local middle school. 8 cases worth.
[12:16:36] <Jymmm> including a networkable color laser printer
[12:17:18] <jepler> lucky them
[12:19:40] <Jymmm> jepler: Not really, the cost per page on this one was expensive
[13:13:03] <SWPadnos> jepler, you're right, disabling the Linux parport driver would have been a good idea
[13:13:40] <SWPadnos> alex_joni, thanks. is /etc/emc2 the only place rtapi.conf can be?
[13:14:17] <SWPadnos> Jymmm, that wasn't very nice
[13:14:37] <Jymmm> SWPadnos: You'll have to be more specific.
[13:14:41] <SWPadnos> heh
[13:14:58] <SWPadnos> donating a cool color network printer that's expensive to actually use to a school
[13:15:19] <Jymmm> Oh, well it's better than none at all.
[13:15:53] <Jymmm> Don't blame me, blame Dell!
[13:16:16] <Jymmm> and NEVER EVER buy a printer from dell... E V E R !!!
[13:16:31] <SWPadnos> ok, I won't
[13:16:44] <alex_joni> SWPadnos: for installed systems yes
[13:16:52] <alex_joni> for RIP it's in scripts/ iirc
[13:16:56] <skunkworks> * skunkworks stares longingly at his dell studio xps.
[13:17:02] <SWPadnos> ok
[13:17:06] <Jymmm> You know how much of a pita it is to box/unbox a 130lb printer that's been replaced three times???
[13:17:15] <alex_joni> but remember there's a rtapi.conf.in which will be used to rebuild the one without in on new ./configure invocations
[13:17:16] <SWPadnos> yes, I think I do
[13:17:55] <SWPadnos> I was thinking of adding an option to the emc script, and/or an environment variable
[13:18:39] <SWPadnos> right around 4.3.2.1 or so
[13:18:50] <SWPadnos> (ie, between 4.3.2 and 4.3.3)
[13:21:33] <SWPadnos> johnt, I think any of true, TrUe, TRUE, 1, and maybe even on or yes should work in halcmd
[13:21:39] <SWPadnos> but pyvcp may be different
[13:22:49] <jepler> pyvcp is Python. In Python, true and TrUe and TRUE are identifiers with no special meaning, and True is a special identifier that means the same as bool(1)
[13:23:05] <SWPadnos> there we go :)
[13:24:17] <SWPadnos> so if we wanted to be crazy, we could lowcase() the whole string, then upcase the first char, then try to assign the actual varuable
[13:24:23] <SWPadnos> but that would be crazy
[13:24:37] <SWPadnos> err, variable
[14:41:21] <JT-Work> cradek: did you see the patch I put up that shows the current coordinate system on the status bar for Axis?
[14:43:46] <cradek> yes but I didn't try it
[14:44:24] <JT-Work> I've been using it on the Hardinge
[14:44:53] <JT-Work> just wanted another pair of eyes to give it a look see to make sure I didn't make any programming errors
[17:39:17] <dgarr> jepler: another try a this:
http://www.panix.com/~dgarrett/stuff/0001-hal_lib-allow-multiple-hal-components-in-simulator-a.patch
[17:46:42] <jepler> dgarr: I have some quibbles about the code style (I wouldn't define the struct inside the function, and I wouldn't put the UUID_KEY in the header, for instance)
[17:47:01] <jepler> dgarr: but more importantly, are you planning to fix the problems under rtai_ulapi as well?
[17:50:34] <dgarr> i guess i don't know what the problems are in rtai_ulapi, if they are related, please describe and i will see if i understand enough to try
[17:50:46] <jepler> I thought you confirmed that one of my test programs gave a segfault
[17:50:46] <dgarr> re the quibbles, np, where should UUID_KEY go?
[17:50:56] <jepler> it's only used in one source file, so place it in the source file.
[17:51:23] <jepler> (if there are other xxx_KEYs that are in that header but are only used in one place then maybe I'm wrong about wanting that)
[17:51:39] <jepler> the struct definition should go just above the function body, OR with other struct definitions at the top of the file if there are any
[17:52:13] <jepler> and I'd go ahead and use the normal 4 space indents in the function since you're replacing the whole body
[17:52:29] <jepler> (I know, you probably expended some effort to get the stupid small indent that is there..)
[17:54:26] <dgarr> re: segfault, i will have to look back at my notes, and do some testing on a machine with realtime, i'll post a new patch today or tomorrow
[17:54:50] <jepler> if you can fix any problems I find with sim or rt then I would not mind seeing this go in
[17:55:15] <jepler> but I don't want it to go in for sim only, since that means you can develop software that won't run on the real machine..
[17:57:31] <dgarr> i understand -- however,so far what i've been trying is to make something work in sim that _already_ works in rt
[18:01:18] <jepler> I understand that some things work with just a little tweaking, but it's still possible to segfault from a plausible-looking sequence of HAL API calls on realtime
[18:37:55] <cradek> haha, G0.0001 X1
[18:50:21] <jepler> how about GTAN[180]X1
[18:52:36] <jepler> or for fun you could also figure out why G[2**30] errors with 'negative g code used'
[19:58:38] <jepler> hmmm .. G0 with no axis words specified still emits a STRAIGHT_TRAVERSE. Same with G1 if an F-number is supplied.
[19:59:03] <jepler> I guess I thought G0 alone just changed the movement type and the presence of at least one axis word produced a movement
[20:30:14] <micges> Dave911: around?
[20:31:27] <JT-Hardinge> micges: do you have time to look at a patch?
[20:34:10] <micges> JT-Hardinge: will hold beer for few minutes :) what have you got?
[20:34:27] <SWPadnos> now thats dedication! :)
[20:34:33] <JT-Hardinge> sure I'll email you a beer
[20:34:55] <JT-Hardinge> just a patch that puts the current coordinate system on the status bar
[20:35:06] <JT-Hardinge> not much to look at
[20:35:42] <micges> jepler didn't look at it yet?
[20:35:47] <alex_joni> JT-Hardinge: pastebin it already :P
[20:35:53] <JT-Hardinge> http://www.pastebin.ca/1876221
[20:36:03] <JT-Hardinge> dunno if he did
[20:36:34] <JT-Hardinge> I'm using it now but just want some more experienced eyes to give it a once over and look for dumb mistakes
[20:36:34] <micges> JT-Hardinge: I know that Axis have problem with showing current offsets, did you looked at it too?
[20:36:47] <JT-Hardinge> next on the list :)
[20:37:14] <JT-Hardinge> or if a tool offset is in effect or not
[20:37:21] <micges> yep
[20:38:01] <JT-Hardinge> each one has allowed me to crash so they are high on my list :)
[20:39:21] <micges> patch is ok for me
[20:39:52] <JT-Hardinge> ok cool I'll commit it later after I'm done making these parts
[20:40:02] <JT-Hardinge> commit it to master right?
[20:41:38] <micges> yes but I would like first let know jepler or cradek
[20:42:05] <JT-Hardinge> cradek looked at it but had no comment
[20:42:26] <JT-Hardinge> might have been busy at the time
[20:50:42] <jepler> JT-Hardinge: it looks OK as long as decreasing the size of info.task_state doesn't make any of the states fail to fit in any of the languages
[20:51:03] <jepler> (but it was made 14 a long time ago, before any translations, so I doubt it was given that specific width for that reason)
[20:51:10] <JT-Hardinge> jepler: how do I test that?
[20:51:53] <jepler> there's no easy way. you have to run with each translation and set the machine in each state, and look whether the result is OK
[20:52:30] <JT-Hardinge> ok, is it possible to look in the .po file I think that is the translation file
[20:53:20] <jepler> you'll be looking at it in a different font than it would be shown onscreen
[20:53:30] <JT-Hardinge> ah ok
[20:53:58] <JT-Hardinge> how do I load a different translation?
[20:54:41] <jepler> don't worry too much about it. I looked at the history and like I said that specific width wasn't set for a good reason, it was always that width since the first commit in 2004
[20:54:50] <jepler> so it can't have been carefully sized for a translation that didn't exist yet..
[20:54:53] <JT-Hardinge> I only reduced it to give the lathe tool room to display
[20:55:14] <JT-Hardinge> ok thanks
[20:55:51] <JT-Hardinge> tool info
[21:24:17] <JT-Hardinge> the max size was 8 characters except for two that were paragraphs and did not fit anyway. So 10 should cover all but the two that didn't fit before anyway
[21:25:49] <cradek> JT-Hardinge: would you remind me of the sequence of events where not having this information in the status bar led to an error/crash?
[21:26:55] <JT-Hardinge> I thought I was in the G54 coordinate system where I had an offset set when I was actually in G55 where I had just set the offset of a tool then I ran the program
[21:27:11] <JT-Hardinge> and crash
[21:27:13] <cradek> ok, so it's not about touch off at all
[21:27:43] <cradek> (or is that why you were in g55 in the first place?)
[21:27:46] <JT-Hardinge> well I was touching off a new tool... in G55 so there were no offsets in effect
[21:27:50] <JT-Hardinge> yes
[21:28:21] <cradek> gotcha
[21:28:32] <JT-Hardinge> the other time I had a tool offset in effect I think when I touched off again or something like that
[21:29:06] <cradek> it seems like touch off is the thing that we could maybe improve - but I'm not sure how
[21:29:08] <JT-Hardinge> ah,no I had the tool loaded but had not done a G43 then touched off the Z on G54
[21:29:13] <cradek> (tool touch off specifically)
[21:29:14] <andypugh> If my opinion matters, I think having the current coordinate system onscreen is such an obvious thing that I am amazed it wasn't always there.
[21:29:50] <cradek> JT-Hardinge: when running a program that uses several systems, does the readout change at the right times?
[21:29:55] <JT-Hardinge> the status bar shows the current tool loaded but not if the offset is in effect or not
[21:30:14] <cradek> yeah, and that's nearly deceptive IMO
[21:30:16] <JT-Hardinge> coordinate systems?
[21:30:33] <JT-Hardinge> I normally run in G54...
[21:30:46] <cradek> I mean a program that does g54 - lots of G1 - g55 - lots of G1 - etc
[21:30:58] <andypugh> Well.. One thing I think might be better in touch-off would be separate tool touch-off and work touch-off buttons (the latter touches off the currently selected coordinate system). If you want to touch off an inactive coordinate system then you go to a menu option, not a button.
[21:31:03] <cradek> does the CS in the status bar switch from g54 to g55 at the right time?
[21:31:31] <JT-Hardinge> yes when you switch in mdi I've not tried in a program
[21:31:36] <jepler> I assume it has the same timeliness issue as the one displayed on the MDI tab during a program run
[21:31:45] <cradek> yeah i'm specifically asking about a running program
[21:31:46] <jepler> i.e., it represents readahead coordinate system, not executing coordinate system
[21:32:01] <cradek> jepler: I think CS switch might be a queue blocker, so we get lucky
[21:32:26] <jepler> is it? that would be mildly pleasant
[21:32:51] <andypugh> If spindle speed change is, it would be eccentric for a coordiante system one not to be
[21:33:02] <cradek> haha eccentric
[21:37:38] <JT-Hardinge> I'll test changing coordiante systems while running later when I finish these parts I'm running now
[21:38:05] <cradek> work sure gets in the way
[21:38:50] <JT-Hardinge> crap I just tried to load a program change with two o100 while loops and it is confused at the least
[21:39:30] <JT-Hardinge> whew it finally gave up :)