Back
[17:39:38] <KimK> cradek: Anyway, I posted 4 lines that were something like (1) Parallel: Parallel port not found(?) (2) Parallel: Continuing anyway (3) PPMC: No USC/UPC for (something, controller?) (4) PPMC: shutting down
[17:41:50] <KimK> Oh wait, I remember. (3) PPMC: No USC/UPC for DAC at port 0, 0 (or something like that) John's BP2 has the optional spindle DAC.
[17:42:41] <KimK> cradek: John says hi.
[17:44:19] <KimK> cradek: We'll be at lunch a bit, then errands, then back after while. Any advice appreciated. Thanks! (And then I'd like to talk more later about your travel plans).
[17:45:05] <skunkworks_> cradek: there is access on each axis to crank them off of the limits... I think that will work for us. ;)
[17:45:06] <SWPadnos> KimK, are there two USC/UPC boards on that system?
[18:27:04] <cradek> oh your ppmc still doesn't work? ugh.
[18:45:17] <jepler> ugh indeed
[18:45:56] <jepler> it is starting to seem like something must be wrong in my conversion to use the new hal_parport_xxx APIs but I haven't spotted it yet
[18:46:20] <jepler> KimK: what is the loadrt line like for ppmc? can you put the exact kernel messages online (pastebin or whatever)?
[18:46:43] <cradek> skunkworks_: great - that is definitely safest if it's accessible
[18:47:00] <skunkworks_> :)
[18:47:16] <skunkworks_> that is how you did it with the old control... Never really had an issue.
[18:48:13] <skunkworks_> soft limits should take care of 99% of the issues/
[18:50:06] <cradek> yeah it's not like you regularly hit limit switches anyway
[18:52:00] <jthornton> I just tried 2.4.1 on John's BP2 again, still failing, I suspect these are the relevant lines (he has the optional spindle DAC):
[18:52:00] <jthornton> [ 1817.879038] PARPORT: linux parport parport0 does not support mode 4.
[18:52:00] <jthornton> [ 1817.879042] PARPORT: continuing anyway.
[18:52:00] <jthornton> [ 1817.882883] PPMC: ERROR: no USC/UPC for extra dac at bus 0, slot 0
[18:52:00] <jthornton> [ 1817.882893] PPMC: shutting down
[18:52:01] <jthornton> Any advice appreciated as always. Thanks!
[18:52:14] <jthornton> KimK, post ^
[18:52:46] <SWPadnos> does anyone know if he has two cards?
[18:52:57] <SWPadnos> I can imagine the enumeration order being different
[18:53:06] <jepler> that's one reason I was interested in the loadrt line
[18:53:09] <SWPadnos> yep
[18:56:31] <dgarr> jepler: maybe this fixes the flakiness:
http://www.panix.com/~dgarrett/stuff/0001-sim_ulapi.c-rtapi_init-should-return-a-unique-identi.patch
[18:56:49] <jepler> dgarr: bzzt.
[18:57:19] <dgarr> ?
[18:57:25] <jepler> dgarr: that means each rtapi_init call in a process will return the same unique ID, but suppose you start process 111 which creates a component, and then process 112 which creates a component
[18:58:02] <dgarr> oops -- whats a good way to make it unique then?
[18:58:34] <jepler> and now that you've rung that bell, I'm pretty sure 'halcmd unload' assumes the userspace component ID is also its process ID for killing them..
[18:59:01] <jepler> (sorry if 'bzzt' read as being rude, it wasn't supposed to)
[18:59:30] <dgarr> np
[19:01:55] <jepler> hmm, looks like a component has a 'pid' field separate from the 'comp_id' field
[19:02:13] <jepler> so the 'halcmd unload' problem isn't
[19:07:28] <jepler> it looks like under rtai IDs are assigned from a pool of small positive integers because all the rtapi modules together maintain the module_array
[19:07:57] <jepler> under ulapi, userspace components get their PID for their ID and realtime components get 32768+small-number, since on typical unix systems PIDs over 32767 are never used
[19:08:21] <dgarr> what about an id based on unix time or something
[19:09:19] <jepler> under rtai, the segfault problem is probably due to any call to rtapi_exit unmapping the rtapi shared memory areas
[19:09:28] <cradek> I haven't been paying enough attention. what problem are you trying to solve?
[19:09:50] <jepler> cradek: dgarr wants to be able to 'package require Hal' in the Tcl part of AXIS, for his own purposes
[19:09:57] <dgarr> problem statement:
http://www.panix.com/~dgarrett/stuff/q1.txt
[19:09:59] <jepler> (I think to be able to run 'halcmd' commands without a pipe)
[19:10:59] <cradek> thanks
[19:11:03] <dgarr> and jepler pointed out problem (09:05:54) jepler: dgarr: git show 8f634b47
[19:11:13] <jepler> hal forbids this, and it does so because of various problems that allowing it lead to. In sim, all hal components in the same process get the same hal component id. In rtai and sim both, various weirdness can be provoked, usually when one hal_exit occurs before all other use of hal is done
[19:47:26] <KimK> Hi all, back after lunch and assorted errands. Thanks jthornton for posting those four error lines. Sorry, that's all I can get for you right now as the machine is in use. (Cleaning up opposite sides of castings with a 4" facemill before grinding, and doing nicely.) I should be able to get you the full error report in 2.5 hours, maybe?
[19:47:51] <JT-Work> np I just remembered them and was at the house for a few minutes
[19:48:54] <KimK> SWPadnos: Only one Pico-Systems Universal Stepper Controller (USC) in John's BP2, and it has the optional spindle DAC.
[19:50:02] <KimK> All running nicely under 2.3.5
[20:01:39] <SWPadnos> ok
[22:19:48] <BridgeportIIa> Oops, I forgot that Synaptic gave an error on the upgrade. It said emc2 upgraded to 2.4.1, but emc2-dev was still at 2.3.5:
http://imagebin.ca/view/MrK8cmn.html
[22:21:52] <BridgeportIIa> Oh, I guess it's OK on the second try, all is OK now. I'll try 2.4.1 and post the errors.
[22:29:19] <jthornton> pyvcp text button <disable_pin> 1, True, TRUE all work but true does not. Is that something with python or the pyvcp_widgets.py?
[22:29:39] <jthornton> Widget button, Property disable_pin
[22:29:39] <jthornton> NameError: name 'true' is not defined
[22:44:00] <BridgeportIIa> OK, here are the EMC2 error window errors, and the tool table:
http://www.pastebin.ca/1875693
[22:45:25] <BridgeportIIa> Any advice appreciated as always. I'll be gone for several hours, but please post.