Back
[02:31:09] <archivist> I see no one responded to slavko's original submission see message [Emc-developers] streamer BUG or feature
[04:16:09] <archivist> rob_h, you seen
https://www.youtube.com/watch?v=ON9m2xwWonM
[04:21:48] <rob_h> not bad... but where is the gear cutting ;)
[04:22:59] <archivist> is he asking to use the video though
[04:24:38] <rob_h> not that i have seen but dont check that email account much
[08:03:18] <wortley> I am trying to clean up my act and export a function that will allow me to get a pointer to my spibuffers. When I call that function from the kernel, I assume it knows nothing about where the spibus.comp __comp_first_inst is. Is there a data structure of names I can traverse to find the __comp_first_inst that I am interested in by name?
[10:02:00] <seb_kuzminsky> archivist: i responded to slavko in the bug tracker:
https://sourceforge.net/p/emc/feature-requests/125/
[10:02:12] <seb_kuzminsky> i gave him feedback which he rejected
[10:06:53] <archivist> I see he is confused about your reply
[10:11:09] <archivist> it may be his first submission, not knowing coding standards
[10:55:07] <seb_kuzminsky> archivist: sure he's confused
[10:55:12] <seb_kuzminsky> he's made commits before:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=155171ceadcb63d1322107a5c72b311c8235e845
[10:57:26] <seb_kuzminsky> i object to his claim that he did the task and was ignored, that's now what happened. he started it, got feedback, didn't do the indicated work, and now is claiming that he was ignored and the only thing needed is to push it to master
[10:58:35] <seb_kuzminsky> slavko wants the feature, and it is welcome in linuxcnc, but the patch to add it is not ready
[10:58:56] <seb_kuzminsky> if slavko's not going to do it, i feel like it's a favor to him to ask a GSoC student to finish it for him...
[10:59:16] <seb_kuzminsky> grump
[11:04:54] <pcw_home> country song:
[11:04:56] <pcw_home> I didn't submit a patch
[11:04:57] <pcw_home> so why is it not there
[11:06:29] <archivist> I can see that, I can also see some language confusion and some impatience, first comment(his) is only after a couple of days
[11:07:13] <seb_kuzminsky> yeap, for sure
[11:08:32] <seb_kuzminsky> i bet everyone thinks the time-to-review-patch-submissions is too long in the linuxcnc project
[11:08:46] <seb_kuzminsky> i know i do
[11:09:26] * seb_kuzminsky shrugs
[11:09:50] <seb_kuzminsky> we all do what we can, what we feel like, and if that's not good enough that's just the way it is
[11:10:02] <archivist> volunteers do what they can in their spare time, what rush!
[11:10:30] <seb_kuzminsky> exactly
[11:11:05] <seb_kuzminsky> and slavko's a volunteer too, who does what he can, and i appreciate that part of the interaction
[11:12:06] <archivist> I was a volunteer committee member on a project, some of the committee was very pushy
[11:14:21] <seb_kuzminsky> pcw_home: my favourite(*) country song is Fred You Were A Good Dog
[11:14:31] <seb_kuzminsky> (*) for some value of favourite
[11:38:25] <pcw_home> Always liked "How can I miss you when you wont go away"
[11:41:05] <seb_kuzminsky> "Aw honey, quit crying, you're watering my beer"
[12:03:29] <pcw_home> "drop kick me Jesus"
[12:09:33] <KGB-linuxcnc> 03Dewey Garrett 052.7 610e8ca 06linuxcnc 10lib/hallib/xhc-hb04.tcl xhc-hb04.tcl: bugfix, new connect, sig names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=610e8ca
[12:09:33] <KGB-linuxcnc> 03Dewey Garrett 052.7 1d02220 06linuxcnc 10(7 files in 4 dirs) xhc-hb04: add man page, update inline docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1d02220
[12:10:52] <linuxcnc-build> build #1395 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1395 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:11:03] <linuxcnc-build> build #1204 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1204 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:11:30] <linuxcnc-build> build #1234 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1234 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:12:39] <linuxcnc-build> build #199 of 1903.clang-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1903.clang-wheezy-amd64/builds/199 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:12:43] <linuxcnc-build> build #715 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/715 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:13:01] <linuxcnc-build> build #865 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/865 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:13:20] <linuxcnc-build> build #1204 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1204 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:13:26] <linuxcnc-build> build #3046 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3046 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:13:52] <linuxcnc-build> build #3047 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3047 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:13:58] <linuxcnc-build> build #2250 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2250 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:14:06] <linuxcnc-build> build #3047 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3047 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:14:44] <linuxcnc-build> build #199 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/199 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:15:24] <linuxcnc-build> build #3048 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3048 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:15:38] <linuxcnc-build> build #3047 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3047 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:15:51] <linuxcnc-build> build #3057 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3057 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:29:24] <seb_kuzminsky> drop kick me buildbot
[12:36:49] <KGB-linuxcnc> 03Dewey Garrett 052.7 a2cb4e1 06linuxcnc 10src/hal/user_comps/xhc-hb04.cc xhc-hb04.cc: LOG_LEVEL constants not available * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a2cb4e1
[12:38:03] <seb_kuzminsky> thanks dgarr
[13:49:00] * Tom_itx puts a patch over his eye
[13:53:13] <pcw_home> arrr?
[14:13:07] <adam3999_> afternoon, guys...
[14:36:20] <adam3999_> i posted an updated on my Q1900M parport issue if anyone wants to take a look
[14:36:21] <adam3999_> http://linuxcnc.org/index.php/english/forum/18-computer/28929-no-input-signals-w-asrock-q1900m-onboard-parport#56539
[14:36:47] <adam3999_> looking for some advice on next steps wrt/ HAL troubleshooting and the parport drivers
[15:03:54] <pcw_home> sure you have the
[15:03:55] <pcw_home> addf parport.0.read base-thread
[15:03:57] <pcw_home> in your hal file?
[15:13:16] <adam3999_> loadrt hal_parport cfg="0x378 out"
[15:13:16] <adam3999_> loadusr -Wn PortTest pyvcp -c PortTest ptest.xml
[15:13:16] <adam3999_> loadrt threads name1=porttest period1=1000000
[15:13:16] <adam3999_> addf parport.0.read porttest
[15:13:16] <adam3999_> addf parport.0.write porttest
[15:13:22] <adam3999_> that is the in the header of the ptest application
[15:14:22] <adam3999_> addf parport.0.read base-thread
[15:14:22] <adam3999_> addf stepgen.make-pulses base-thread
[15:14:22] <adam3999_> addf charge-pump base-thread
[15:14:22] <adam3999_> addf pwmgen.make-pulses base-thread
[15:14:22] <adam3999_> addf parport.0.write base-thread
[15:14:22] <adam3999_> addf parport.0.reset base-thread
[15:14:32] <adam3999_> and that is in my mill's .ini file
[15:17:49] <pcw_home> not ptest, regular hal file
[15:18:15] <adam3999_> yep, it's in my mill's normal .hal file
[15:18:57] <adam3999_> # Generated by stepconf 1.1 at Wed Mar 4 21:20:28 2015
[15:18:57] <adam3999_> # If you make changes to this file, they will be
[15:18:57] <adam3999_> # overwritten when you run stepconf again
[15:18:57] <adam3999_> loadrt trivkins
[15:18:57] <adam3999_> loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EM
[15:18:58] <adam3999_> CMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
[15:18:58] <adam3999_> loadrt hal_parport cfg="0 out"
[15:18:59] <adam3999_> setp parport.0.reset-time 1000
[15:18:59] <adam3999_> loadrt stepgen step_type=0,0,0
[15:19:00] <adam3999_> loadrt charge_pump
[15:19:00] <adam3999_> net estop-out charge-pump.enable iocontrol.0.user-enable-out
[15:19:01] <adam3999_> net charge-pump <= charge-pump.out
[15:19:01] <adam3999_> loadrt pwmgen output_type=1
[15:19:02] <adam3999_> addf parport.0.read base-thread
[15:20:06] <adam3999_> i had 0x378 earlier and was testing "0" instead for the parport address, that is still left in there
[15:20:57] <skunkworks> you say out put works though - right?
[15:21:24] <adam3999_> yep, no issues
[15:21:32] <adam3999_> good rapids with the outputs on pins 2-7
[15:22:05] <adam3999_> it's an Asrock Q1900M motherboard with the onboard lpt attached to a leadshine MX3660
[15:27:30] <pcw_home> you have a IDC type flat cable from the header to the DB25?
[15:28:49] <adam3999_> yes
[15:28:59] <adam3999_> idc26 --> db25f
[15:29:12] <adam3999_> i don't see how all of the inputs and outputs would line up just fine if the cable was wrong
[15:29:45] <adam3999_> when i run ParallelPortTest, i can drive my XYZ step pins by clicking rapidly
[15:30:04] <adam3999_> and i can see my limit switches on pins 10-12, and e-stop on 15
[15:30:37] <adam3999_> i can't see how having all of those pins lined up correctly could occur if it was mis-wired
[15:31:39] <pcw_home> OK so it looks to be wired properly
[15:31:40] <pcw_home> when you look at the inputs with hal watch are the (non-working) inputs high or low?
[15:33:50] <adam3999_> they're false
[15:33:55] <adam3999_> in hal meter
[15:34:00] <adam3999_> ptest.hal shows them all red
[15:35:05] <pcw_home> Thats a bit odd, have you tried pulling them up externally?
[15:35:15] <adam3999_> yep
[15:35:29] <adam3999_> that is what leads me to believe it's a low level parport/hal issue tied to my HW
[15:35:37] <adam3999_> i can boot up this PC with nothing even attached to the motherboard lpt header
[15:35:45] <adam3999_> and when i run the ptest.hal app, all inputs are red
[15:35:59] <skunkworks> micges: I think the planner still stops..
[15:36:04] <adam3999_> i've tried that same thing on 2 other PCs i have, and each time the input pins 10-15 show up as green immediately
[15:36:09] <pcw_home> Thats assuming the inputs have pullups
[15:36:10] <skunkworks> at end of each segment
[15:36:17] <adam3999_> and then if i show, say pin 10 for example, they will go from red to green
[15:36:53] <adam3999_> s/show/short/
[15:37:01] <pcw_home> if you measure the input pins with a voltmeter are they at a high level?
[15:37:20] <adam3999_> 0 VDC
[15:37:35] <adam3999_> i can watch my outputs go from 0 to 3.3V when i activate a pin via HAL
[15:37:37] <adam3999_> inputs do nothing
[15:37:58] <adam3999_> let me put the multimeter on one more time just to confirm for you
[15:40:28] <adam3999_> ok multimeter V+ lead is on pin 3 and GND is on pin 22
[15:40:35] <adam3999_> i have ptest.hal open and when i click on pin 3, i go from 0V --> 3.3V
[15:41:32] <adam3999_> when i move the V+ loead over to pin 10, the multimeter moves from 0.00 to 0.01V
[15:41:53] <adam3999_> if i then short the two multimeter leads together, to drive pin 3 straiaght into pin 22gnd, nothing happens in ptest
[15:41:56] <adam3999_> everything stays red
[15:42:11] <pcw_home> OK so that indicates either that the port is not in the expected mode or has no input pullups
[15:42:45] <pcw_home> so now try pulling the input high with a say 1K resistor
[15:42:59] <pcw_home> (connected to +5V)
[15:43:06] <adam3999_> ok no prob, but before i do, i should mention again that this works just fine with the ParallelPortTest app
[15:43:31] <adam3999_> when i short pin 10 to 22, i can see the green light in that app bouncing on/off each time to indicate the inputs are being seen
[15:44:14] <adam3999_> and that same pathway works all the way through my MX3660, i can toggle the e-stop (Which drives pin 15) and i can see pin 15 toggle green/off/green/off in that other app
[15:45:16] <adam3999_> i've got a 1.8K ohm 1/4W resistor, will that work ok?
[15:45:28] <pcw_home> Yes
[15:46:23] <adam3999_> ok, i put the 1.8K between 10 and 22 and no change on ptest.hal
[15:46:26] <adam3999_> was red, still red..
[15:46:52] <pcw_home> 10 and +5 not gnd
[15:47:02] <adam3999_> oh sorry
[15:47:16] <adam3999_> can you let me know a good spot to get +5V?
[15:47:21] <adam3999_> my pins appear to all be 3.3V
[15:47:27] <micges> skunkworks: what do you mean?
[15:47:39] <adam3999_> i can wire off of a 5V rail on the ATX power supply?
[15:47:45] <adam3999_> that should have a common ground with the parallel port
[15:47:48] <pcw_home> safest is usually a cut USB cable
[15:48:09] <adam3999_> or perhaps a PS2 keyboard/mouse pin?
[15:48:35] <pcw_home> if you use the ATX 5V be careful you dont short the 5V out (>50A current possible)
[15:49:30] <adam3999_> ok give me a moment maybe i can tap a usb pin without cutting my cable
[15:49:33] <micges> skunkworks: heh I've missed deadline with jerk code so I needed to show him CAB planner
[15:49:43] <adam3999_> so +5V - 1.8K -- lpt pin 10
[15:50:07] <adam3999_> i'm assuming this lpt port is 5V tolerant, even though it outputs 3.3v ....? :)
[15:50:45] <pcw_home> Yes by spec (and even if it was not the 1.8K will protect it)
[15:56:03] <adam3999_> ok
[15:56:06] <adam3999_> after i put the fire out
[15:56:10] <adam3999_> haha jk
[15:56:17] <adam3999_> no input, still red on ptest.hal
[15:56:37] <adam3999_> i drove 5V from a usb cable attached to the linuxcnc PC through the resistor into pin 10
[15:58:28] <adam3999_> is it possible that the parallel port isnt being initialized by HAL or the other linuxcnc components somehow
[15:58:37] <adam3999_> but that the ParallelPortTest app does do something correctly to initialize it?
[15:59:20] <adam3999_> i saw some forum traffic about folks using a piece of software to set the mode of their parallel port, but i think that was because they didn't have an easy way to set EPP in their bios. mine is set EPP-1.9 via BIOS (has surprisingly a lot of parallel port options in there)
[16:00:29] <pcw_home> What does pin 10 read when pulled up?
[16:01:22] <adam3999_> would you like me to put the multimeter between pin 10 and the lpt ground pin 22 while i pull it up via the 5V and resistor?
[16:03:12] <pcw_home> yes
[16:03:15] <adam3999_> ok 1s
[16:06:20] <adam3999_> hm that is strange, nothing there
[16:06:46] <adam3999_> either this usb 5v is not present (unlikely) or perhaps the lpt ground and usb ground are not shared
[16:07:39] <pcw_home> They are shared so if you connect the voltmeter to the 1.8K resistor it should read roughly 5V
[16:11:26] <adam3999_> hm
[16:11:35] <adam3999_> ok so i just knocked some cables out and rebooted my cnc pc
[16:11:59] <adam3999_> and happened to notice that when POSTing, the multimeter read 3.3V from pin 10 to pin 22
[16:12:11] <adam3999_> then it went into an intermediate state around 1.4-1.5V during boot
[16:12:19] <adam3999_> and when i ran halrun -I -f ptest.hal, it dropped to 0
[16:13:25] <pcw_home> looks like something puts it into a bogus mode (ECP?)
[16:13:36] <adam3999_> yeah that's what im starting to think
[16:13:42] <adam3999_> something sw related is putting it in a bad mode
[16:13:55] <adam3999_> are there any OS tools that can force it into a specific mode?
[16:14:14] <adam3999_> [ 7.323100] parport_pc 00:06: reported by Plug and Play ACPI
[16:14:14] <adam3999_> [ 7.323180] parport0: PC-style at 0x378 (0x778), irq 5 [PCSPP,TRISTATE]
[16:14:14] <adam3999_> [ 9.989797] lp0: using parport0 (interrupt-driven).
[16:14:14] <adam3999_> [ 10.010264] ppdev: user-space parallel port driver
[16:14:24] <adam3999_> it's just the standard onboard lpt port
[16:15:17] <adam3999_> looking at that dmesg out, however it does say "SPP"
[16:15:25] <adam3999_> and i have it setup as EPP-1.9 in the bios
[16:15:28] <pcw_home> look like too many cooks in the kitchen
[16:15:55] <adam3999_> hm?
[16:18:58] <pcw_home> someone pokes at something they ought not to or the hardware doesnt follow IEEE-1284 address/register specs (only some do)
[16:19:12] <adam3999_> gotcha
[16:20:35] <pcw_home> theres a utility poking around that sets/reads the PP mode, might be informative
[16:21:02] <adam3999_> i was just looking at these code snippets:
http://as6edriver.sourceforge.net/Parallel-Port-Programming-HOWTO/modeselect.html
[16:21:13] <adam3999_> but i do remember seeing something else related to linuxcnc about setting parport modes
[16:24:03] <pcw_home> Yeah a long time ago this was an issue with the Intel D525 MBs, you could set the PP anyway you wanted in the BIOS
[16:24:05] <pcw_home> but the hardware setup never changed...
[16:24:36] <pcw_home> not even the address
[16:24:48] <adam3999_> hm
[16:25:00] <adam3999_> yeah i was able to toggle between 0x378 and 0x278 with my bios
[16:25:17] <pcw_home> well thats a good sign
[16:25:22] <adam3999_> but same behavior when i set the mode between normal, bi-direction, EPP-1.7 and EPP-1.9
[16:25:41] <adam3999_> with the
[16:26:00] <adam3999_> with the factory BIOS as well as the v1.5 latest update
[16:26:31] <pcw_home> does the pp related part of dmesg change when you change modes?
[16:26:58] <pcw_home> maybe the BIOS isn't really doing anything
[16:27:22] <adam3999_> well, it says PCSPP right now, and i know it's set to EPP-1.9
[16:27:33] <adam3999_> so that's an issue right there IMO
[16:27:46] <adam3999_> i can reboot and set it to like bidirectional or normal and see if the PCSPP string changes
[16:28:03] <adam3999_> #include <stdio.h>
[16:28:03] <adam3999_> #include <sys/ioctl.h>
[16:28:03] <adam3999_> #include <linux/parport.h>
[16:28:03] <adam3999_> #include <linux/ppdev.h>
[16:28:03] <adam3999_> int main()
[16:28:04] <adam3999_> {
[16:28:04] <adam3999_> int parportfd;
[16:28:05] <adam3999_> int mode = IEEE1284_MODE_ECP;
[16:28:05] <adam3999_> int result = ioctl(parportfd,PPNEGOT,&mode); /* 0 on success, -1 on failure */
[16:28:15] <adam3999_> if the result of that ioctl is -1, you can't change the mode
[16:28:17] <adam3999_> and it was...
[16:31:06] <adam3999_> err, wait bug in this code...
[16:47:20] <adam3999_> hm
[16:47:21] <adam3999_> ok
[16:47:31] <adam3999_> i tried using a snippet of code out from the web to set the parport mode 3 different ways
[16:47:44] <adam3999_> the ioctl() returns success but cat /proc/sys/dev/parport/parport0/modes shows "PCSPP,TRISTATE" still no matter what
[16:48:00] <adam3999_> is SPP a parallel port mode where outputs would work but inputs would not?
[16:48:43] <pcw_home> Im still curious if th einput will work if you supply a pullup
[16:51:03] <adam3999_> ok want to test that again?
[16:51:14] <adam3999_> i can put 5V in from the red pin on my HD connector
[16:52:54] <pcw_home> Yeah that should work if you are careful to _not_ short it out
[16:54:32] <adam3999_> ok so i haven't run anything HAL related
[16:54:41] <adam3999_> and pin 10 is at +1.14 VDC
[16:54:52] <adam3999_> measured between pin 10 and pin 22 on the parport
[16:55:01] <adam3999_> so you want me to try +5V again through the 1.8K resistor to pin 10
[16:55:05] <adam3999_> and see if the multimeter changes state
[16:56:23] <adam3999_> ok yep, went from 1.14V--> 3.57V
[16:56:39] <adam3999_> not sure why we didn't get a good voltage on the usb cable, but it looked fine from the ATX connector
[16:57:32] <pcw_home> so does halmeter/whatever change now?
[16:58:46] <adam3999_> ok so running halrun -I -f ptest.hal drops the multimeter down to 0.01V
[16:58:51] <adam3999_> and i have nothing but red pins
[16:59:00] <adam3999_> want to try and pull it up with 5VDC again?
[16:59:35] <pcw_home> Yes read when pulled up (via hal and meter)
[17:00:14] <adam3999_> oh my my
[17:00:27] <adam3999_> yep, multimeter goes 0-->3.xV and i can finally frickin see a green dot on ptest.hal
[17:01:11] <adam3999_> 0.01-->3.14VDC on pin 10
[17:01:38] <adam3999_> getting somewhere... woot
[17:03:34] <adam3999_> so is this a linux parport mode issue
[17:04:05] <adam3999_> or do i need to put some type of db25 adapter in-line with my parport and MX3660 that pulls up the input pins to 5V?
[17:04:59] <pcw_home> Probably a mode issue
[17:06:38] <adam3999_> any thoughts on how to track it down further?
[17:06:54] <adam3999_> thanks very much for the help so far, btw
[17:08:39] <pcw_home> maybe finding the pp mode read/set utility would help
[17:08:40] <pcw_home> or read up on ieee-1284 registers and see what the source is doing
[17:13:25] <pcw_home> wonder whats different with the MBs I have?
[17:13:41] <adam3999_> yeah dunno
[17:13:52] <pcw_home> different SuperIO chip? I though they were all ITE
[17:14:38] <adam3999_> what can i show you
[17:14:41] <adam3999_> lspci -vvv ?
[17:17:09] <pcw_home> its not PCI, probably best to look at board
[17:19:16] <adam3999_> bingo
[17:19:16] <adam3999_> http://www.nuvoton.com/hq/products/cloud-computing/i-o/super-i-o-series/nct6776d/?__locale=en
[17:19:18] <adam3999_> not ITE
[17:19:43] <adam3999_> The NCT6776D is a member of Nuvoton’s Super I/O series capable of monitoring critical parameters in PC hardware including power supply voltages, fan speeds and temperatures. The NCT6776D supports both high accuracy current mode sensing and low cost thermistor mode sensing. The NCT6776D also supports the Nuvoton SMART FAN™ I and SMART FAN™ IV algorithms for fan speed control.
[17:19:44] <adam3999_> The NCT6776D supports Printer Port, KBC, 2 UART and GPI/O.
[17:21:08] <pcw_home> also has low power mode... hmmm
[17:23:23] <pcw_home> like how those are listed under "cloud computing"
[17:24:01] <adam3999_> ha
[17:27:10] <pcw_home> I'm signing up for an account...
[17:28:08] <adam3999_> i see lots of linux hw monitoring tools that have support for that chip
[17:28:21] <adam3999_> they are readinh/writing addresses that talk to it
[17:28:41] <adam3999_> i wonder if we could strip some of that code and talk to that chip and manually set some of its parallel port functionality
[17:28:59] <adam3999_> instead of fan speeds and temps
[17:29:17] <pcw_home> that part _should_ be independent and IEEE-1284 compatible
[17:29:36] <adam3999_> and yet, here we are :)
[17:31:23] <adam3999_> oot@linuxcnc:~# superiotool
[17:31:23] <adam3999_> superiotool r6637
[17:31:23] <adam3999_> Found Nuvoton NCT6776F (C) (id=0xc333) at 0x2e
[17:31:23] <adam3999_> root@linuxcnc:~#
[17:31:27] <adam3999_> i can dump registers and such with this tool
[17:32:13] <adam3999_> LDN 0x01 (Parallel Port)
[17:32:13] <adam3999_> idx 30 60 61 70 74 f0
[17:32:13] <adam3999_> val ff ff ff ff ff ff
[17:32:13] <adam3999_> def 01 03 78 07 04 3f
[17:32:22] <adam3999_> those are the parport registers, whatever the heck they represent...
[17:33:26] <pcw_home> well data sheet might help
[17:38:08] <pcw_home> I wonder if linuxcnc's mode setting stuff preserves what it thinks are dont-care mode register bits
[17:39:20] <adam3999_> http://media.digikey.com/pdf/Data%20Sheets/Nuvoton%20PDFs/NCT6776F,D.pdf
[17:39:37] <adam3999_> not sure
[17:39:50] <adam3999_> i do think it's interesting that after boot, the parport inputs are floating around 1.15V
[17:40:19] <adam3999_> and when i run that separate ParallelPortTest utility, it will move up to 2.xVDC when in input mode, then when it exits it leaves it again in an intermediate state
[17:40:36] <adam3999_> as soon as i run anything HAL related, inputs rop to 0.01VDC
[17:40:46] <adam3999_> so those tools are definitely doing different things wrt/ mode setting
[17:47:13] <adam3999_> ok so i see on pg 229 a table showing available parport modes
[17:47:32] <adam3999_> and they can be changed by setting 3 bits in a register
[17:52:32] <pcw_home> With pullup, inputs should be ~3.3V.
[17:53:38] <pcw_home> now you just need a utility to read/write the config regs
[17:54:37] <pcw_home> out 0x778 7
[17:54:38] <pcw_home> etc
[17:55:07] <adam3999_> this superiotool has a regwrite() function in it...
[17:55:28] <adam3999_> void regwrite(uint16_t port, uint8_t reg, uint8_t val)
[17:55:28] <adam3999_> {
[17:55:28] <adam3999_> OUTB(reg, port);
[17:55:28] <adam3999_> OUTB(val, port + 1);
[17:55:28] <adam3999_> }
[17:55:34] <adam3999_> not sure if that is going to actually achieve what we want
[17:56:17] <adam3999_> can you explain what you mean by 0x778 7 ?
[17:58:36] <pcw_home> ECR register is base +0x402
[17:58:38] <pcw_home> so actually 0x77A
[17:59:32] <adam3999_> ah, above the 0x378 base, roger
[18:00:25] <adam3999_> and 0x7 is 100, which is the EPP mode setting?
[18:01:35] <pcw_home> oops that wrong mode is in top 3 bits
[18:02:11] <adam3999_> yeah i was gonna ask, i think we need a mask or something
[18:02:18] <adam3999_> just to manipulate those top bits 5-7 and leave 0-4 alone
[18:02:37] <pcw_home> probably leave alone
[18:04:42] <pcw_home> well actually last bits could be 0x14 (disable DMA and IRQs)
[18:13:03] <adam3999_> whoops, sorry wifi dead
[18:13:20] <adam3999_> so i'm trying to think how i could use the regwrite command
[18:14:02] <adam3999_> if port is 0x378, reg is 0x402, and then the value parameter is a string that will turn on EPP
[18:15:16] <pcw_home> ECR is base (0x378) + 0x402 = 0x77A
[18:15:41] <adam3999_> correct, but if you look at the regwrite function above, it's got a port then register argument
[18:15:50] <adam3999_> so i was thinking port would be the 0x378 base addr
[18:16:12] <pcw_home> doesnt apply to parallel port
[18:16:36] <adam3999_> ok so regwrite( 0x77A, ??, ?? );
[18:16:49] <adam3999_> or we can just OUTB() and forget regwrite()
[18:16:51] <pcw_home> ox77a is direct read/write I/O access
[18:17:36] <pcw_home> INB might be more informative (at least to see whats gone wrong)
[18:18:34] <pcw_home> since I/O is protected it might be easier to dig up the PP mode utility
[18:18:45] <adam3999_> any idea what it was called?
[18:19:44] <pcw_home> its been years since I messed with any of that :-(
[18:23:47] <pcw_home> http://pico-systems.com/codes/pcisetup.tgz
[18:23:48] <pcw_home> if its still there
[18:24:18] <adam3999_> yep
[18:24:29] <adam3999_> got it
[18:26:52] <adam3999_> adam@linuxcnc:~$ sudo ./pcisetup 0x378
[18:26:52] <adam3999_> io addr = 378
[18:27:24] <adam3999_> any more to the app than this?
[18:27:40] <adam3999_> adam@linuxcnc:~$ cat /proc/sys/dev/parport/parport0/modes
[18:27:40] <adam3999_> PCSPP,TRISTATE
[18:27:52] <adam3999_> mode looks the same, although i don't know how often that proc file gets updated
[18:32:17] <pcw_home> does pcisetup have any help/usage hints
[18:33:08] <adam3999_> nope
[18:33:13] <adam3999_> just says sudo ./pcisetup 378
[18:33:20] <adam3999_> on the pico website
[18:33:25] <adam3999_> its a workaround for some old dell PCs
[18:33:32] <adam3999_> doesn't seem to work for me
[18:33:37] <adam3999_> and unfortunately it's just a binary, no source
[18:34:06] <pcw_home> does it change in input behavior
[18:34:10] <pcw_home> ?
[18:34:13] <adam3999_> no
[18:35:40] <pcw_home> well weird...
[18:35:42] <pcw_home> might look at the linuxcnc code to see what it does
[19:04:18] <pcw_home> maybe try blacklisting the existing linux drivers
[19:04:47] <pcw_home> ( hal_parport does not touch the mode AFAICS )
[19:11:37] <pcw_home> so if the mode is broken at startup (inputs go low) it may well be a linux driver what done it
[19:12:08] <adam3999_> i dont think hal_parport will load without the parport and parport_pc modules already there
[19:12:15] <adam3999_> so i could try blacklisting ppdev and lp only
[19:12:37] <pcw_home> yeah
[19:12:43] <adam3999_> i think i've effectively done that manually with no luck
[19:12:48] <adam3999_> but probably not tried from a clean boot
[19:13:05] <adam3999_> and you guys wouldn't believe that i had it cabled correctly :)
[19:13:10] <pcw_home> you would probably have to do it automatically
[19:14:24] <pcw_home> since it looks to be broken forever once something pokes it the wrong way
[19:16:21] <pcw_home> if blacklisting ppdev and lp doesnt work you could blacklist parport and parport_pc to see where the damage occurs
[19:16:47] <adam3999_> ok just booted with lp, ppdev and parport_pc blacklisted
[19:16:54] <adam3999_> ran ptest and no joy
[19:17:02] <adam3999_> i then manually added back parport_pc and ran ptest again, no joy
[19:17:32] <pcw_home> more importantly use your multimeter on pin 10
[19:18:21] <pcw_home> power cycle with everything blacklisted and see if your pullups still disappear
[19:18:48] <adam3999_> ok
[19:18:50] <adam3999_> install parport /bin/true
[19:18:50] <adam3999_> install parport_pc /bin/true
[19:18:50] <adam3999_> install ppdev /bin/true
[19:18:50] <adam3999_> install lp /bin/true
[19:18:53] <adam3999_> im going to reboot with all 4 blacklisted
[19:19:03] <pcw_home> power cycle
[19:19:04] <adam3999_> that is the contents of my /etc/modprobe/linuxcnc.conf
[19:19:28] <pcw_home> never trust that reboots reset everything
[19:20:04] <pcw_home> especially magic buried register settings
[19:20:37] <adam3999_> ok
[19:20:46] <adam3999_> hit the reset button
[19:20:56] <adam3999_> and i've had 1.99V across pin 10 to pin 22 on the parport since POST
[19:21:10] <adam3999_> and none of those 4 modules were loaded
[19:21:42] <pcw_home> I thought you had 3.3V at one point
[19:21:57] <adam3999_> yeah i saw 3.3V during POST once
[19:22:07] <pcw_home> maybe a mode setting
[19:22:08] <adam3999_> i can power cycle again to see if maybe i just missed it
[19:22:30] <adam3999_> looks like it's in no mans land between 0 and 3.3
[19:23:18] <adam3999_> what should we test
[19:24:31] <pcw_home> you might try the other modes in the BIOS now that no ones poking at the port anymore
[19:25:58] <adam3999_> to see if the lpt port pin 10 shows a different voltage at boot?
[19:26:31] <pcw_home> yes worth a last try before adding pullups
[19:27:54] <adam3999_> ok
[19:28:23] <adam3999_> i changed the bios from Auto address & IRQ ECP/EPP-1.9 to auto address & IQR "normal" mode
[19:28:31] <adam3999_> saved bios, then hard reset again
[19:28:44] <adam3999_> this time it was 1.99V until POST and it dropped down to 1.28V
[19:29:06] <adam3999_> so looks like the BIOS settings are doing something at least
[19:30:48] <pcw_home> sigh... maybe it simply has no pullups and ASRock assumed it did
[19:31:56] <adam3999_> the Q1900M (mine), Q1900M Pro3 and Q1900-ITX all have the nuvoton super IO chip
[19:32:05] <adam3999_> if you zoom in on the newegg motherboard photos
[19:32:22] <adam3999_> i didn't see ITE stamps anywhere
[19:32:30] <adam3999_> so i'm still lost how yours worked
[19:33:13] <pcw_home> maybe some have pullups on the motherboard
[19:33:46] <adam3999_> is there some kind of passthrough DB25 connector that is sold to pull up certain pins
[19:33:58] <adam3999_> or i wonder if i just add them into this
[19:34:19] <adam3999_> it's gotta be related to mode setting with linuxcnc or hal related code, though
[19:34:20] <pcw_home> Not that i know off (it would need 5V from the PC)
[19:34:22] <adam3999_> since that other tool works...
[19:35:01] <pcw_home> might be marginal even with the other tool (1.99V is _probably_ a high)
[19:37:18] <pcw_home> And i just tested by
[19:37:20] <pcw_home> non-inverted pins read as high at startup
[19:37:21] <pcw_home> shorting to ground read as low
[19:37:23] <pcw_home> after releasing they went back high
[19:38:22] <pcw_home> a more thorough test would use the meter on mA range and ground through the meter to calculate pullup resistor value
[19:38:28] <adam3999_> yeah that is what i noticed on my laptop
[19:38:48] <adam3999_> as
[19:39:03] <adam3999_> as soon as i start up ptest, i see all the inputs except 1 already green
[19:39:09] <pcw_home> not sure theres any spec that says inputs must have pullups
[19:39:13] <adam3999_> then you short pin 10, and since it's active low, it goes green-->red
[19:39:32] <adam3999_> so this is interesting, i booted with all 4 modules blacklisted, then removed just parport from the blacklist and manually added it
[19:39:33] <pcw_home> but its common and obviously depended on by some hardware
[19:39:53] <adam3999_> i ran ptest now and when i click on outputs, my multimeter goes from 0.0 to 0.3V on pin 10
[19:39:58] <adam3999_> almost like interference from the output voltage
[19:40:39] <pcw_home> leakage
[19:41:00] <adam3999_> yea
[19:41:03] <pcw_home> .3v into 10M is 30 nA
[19:41:47] <pcw_home> screw it get a 5 pin sip resnet and solder on back of header
[19:42:29] <pcw_home> 3.3K maybe
[19:43:18] <adam3999_> how would that work, 5V on one side and each other leg of the resistor network on each of the input pins?
[19:43:55] <adam3999_> i could put all 3 homing switches on 10 and use 15 for e-stop
[19:44:04] <adam3999_> and get away with one two pins pulled up for a while
[19:44:05] <pcw_home> yep 5V to common and the one leg to each input
[19:44:52] <pcw_home> or just 1/4 or 1/8 w resistors
[19:45:43] <adam3999_> i used to have one of those db25 breakout boards for manually pinning oddball series ports
[19:45:47] <adam3999_> would be perfect for this
[19:48:15] <adam3999_> pcw, one last thing to consider
[19:48:23] <adam3999_> i have a 48V server p/s that has a 12V 4A standby power source
[19:48:38] <adam3999_> that 12V 4A is driving the Q1900 motherboard via a pico ATX power supply
[19:48:49] <adam3999_> i figured 50W would be plenty to drive it
[19:49:07] <adam3999_> and several days ago thought that this issue could be related the MB not getting enough juice
[19:49:28] <adam3999_> but i replaced that pico ATX power supply with a standard 350-500W ATX power supply and it behaved exactly the same
[19:49:32] <adam3999_> food for thought
[19:50:12] <pcw_home> if the outputs can swing to 3.3V any internal pullups should work also
[19:51:07] <pcw_home> one last software thing to try is read/write the buried pp config register (page 333)
[19:53:33] <adam3999_> any thoughts on how to write that
[19:53:39] <adam3999_> outb() ?
[19:54:00] <pcw_home> doesn't that utility help you
[19:54:20] <adam3999_> ready only
[19:54:26] <pcw_home> its one of the index register things
[19:54:35] <adam3999_> was looking at using regwrite() but didn't know the right arguments
[19:55:06] <adam3999_> LDN 0x01 (Parallel Port)
[19:55:06] <adam3999_> idx 30 60 61 70 74 f0
[19:55:06] <adam3999_> val 01 03 78 05 04 3c
[19:55:06] <adam3999_> def 01 03 78 07 04 3f
[19:55:08] <adam3999_> those are the regs it dumps
[19:55:30] <pcw_home> may simply be that there are no pullups
[20:01:03] <adam3999_> i'm alreadying wiring a db25 lol
[20:03:35] <adam3999_> i've got 1K, 1.8K and 2.2K
[20:03:53] <adam3999_> i might as well do all 4 inputs plus the e-stop, 5 total
[20:05:00] <adam3999_> what resistence do you recommend? i'll put +5V into one leg of all of them, and the other on pins 10 - 13, 15
[20:06:05] <pcw_home> 2.2 is fine
[20:06:08] <adam3999_> ok
[20:06:21] <adam3999_> 2.2K 1/4W 5% carbon
[21:01:05] <adam3999_> heh
[21:01:11] <adam3999_> pcw, you're not gonna believe this
[21:01:21] <adam3999_> just wired those 5 resistors up, same thing
[21:01:24] <adam3999_> no green inputs
[21:03:22] <pcw_home> no 5V?
[21:04:07] <adam3999_> i took the same 5V from the ATX power connector and tied it into one side of all 5 2.2K resistors
[21:04:27] <adam3999_> then i put the opposite leg of each resistor on pins 10-13, 15
[21:04:41] <adam3999_> i had a ribbon db25 cable that i took out of the backshell, extended and re-crimped
[21:06:26] <pcw_home> check inputs for working pullups (all should measure > 3.3V)
[21:07:34] <adam3999_> hmm
[21:07:34] <adam3999_> not there
[21:07:38] <adam3999_> what the f...
[21:09:42] <adam3999_> ah hm, now i legitimately have the wrong pinout haha
[21:10:52] <adam3999_> ended up on pins 6,7,8, 18 and 19
[21:10:57] <adam3999_> i terminated the db25 wrong :)
[21:12:23] <adam3999_> duh, the ribbon cable is pins 1, 14, 2, 15 ...
[21:14:24] <pcw_home> the rows are 1-1 pin the DB25 is numbered differently...
[21:14:44] <pcw_home> s/pin/but/
[21:16:33] <adam3999_> lol
[21:16:41] <adam3999_> alright... soldering iron back on
[21:16:46] <adam3999_> that ones on me
[22:13:56] <adam3999_> ok pcw
[22:14:10] <adam3999_> 3 working limit switches and a functional e-stop
[22:14:15] <adam3999_> i assume pin 13 is fine as well
[22:14:17] <adam3999_> THANK YOU
[22:23:43] <adam3999_> x axis homes itself... that deserves a beer