Back
[01:13:24] <dgarr> jepler: nojoy
http://www.panix.com/~dgarrett/stuff/parport_test_2.txt
[01:30:35] <jepler> dgarr: thanks
[01:31:59] <jepler> hm, you took down the first set of results? drat.
[01:32:59] <dgarr> no, but fixed a typo in name, see:
http://www.panix.com/~dgarrett/stuff/parport_test.txt
[01:33:04] <jepler> ok thanks
[01:33:17] <jepler> so it's much worse with the patch than without
[01:33:32] <jepler> the last patch, anyway
[01:43:43] <jepler> hm, here's some "duh" the code I wrote, but I don't understand how it would relate to the detection failures
[01:49:45] <jepler> I suppose I should try the code on my own -- it'll at least get as far as not detecting pico hardware if it's working, or fail if not ..
[03:05:13] <Dave911> >>(oops not 29 but 19 bytes for 5word group write, still >16 FIFO size)
[03:05:15] <Dave911> I had this same data exchange running on this same PLC with Mach3 Modbus and never got any errors - if anything would be susceptable to thread swaps delays you would think it would be a windows based program - but that has not been the case.
[03:05:17] <Dave911> Does anyone know the history of the Modbus code? Was it added in as an open source package - ala Classic Ladder? If I get a chance I'll figure out more details on the error as it is very repeatable and let everyone know. Depending on how it is coded in EMC2, I might be able to also find the error - if it turns out to be a code error.
[03:22:00] <mozmck> there's a modbus.c/h in src/hal/user_comps
[03:22:18] <mozmck> Don't know if that's what you need for sure...
[03:31:05] <dgarr> jepler: no solution but some observations:
http://www.panix.com/~dgarrett/stuff/notes_1.txt
[04:20:24] <pcw_home_> Easy way to verify if its a timing issue is to lower baud rate, if problem goes away, its a timing issue
[04:20:26] <pcw_home_> modbus.c users the standard linux serial port driver I wonder if that it gives any guarantees about
[04:20:27] <pcw_home_> delays in xmit data stream....
[13:06:59] <jepler> dgarr: thanks for the noes, reading them now
[13:11:53] <jepler> dgarr: the switched size/base call in parport_common is the duh I found
[13:12:20] <jepler> but I hadn't figured out that it was the function declarations that were causing me to be so very confused
[13:42:30] <alex_joni> Dave911 & others: there was an modbus protocol implementation error discovered by some german guy
[13:42:49] <alex_joni> I meant to translate and send it to cmorley (iirc he was the one adding CL+modbus)
[13:44:29] <alex_joni> http://www.cncecke.de/forum/showpost.php?p=443394&postcount=16
[13:44:38] <alex_joni> not sure if that's readable for people not subscribed there
[13:59:49] <Dave911> I'm not registered and it looks like I can't get it - also my German isn't very good ... ;-) I saw Cmorley on the forum - perhaps I'll try and contact him there.
[13:59:51] <Dave911> FWIW, The Forum is pretty hard to find for a Newbie. Perhaps the link could be made more obvious on the support page ??
[15:07:21] <jepler> aha, there were two places to check for the "unspecified" parport address
[15:07:25] <jepler> and a bug in the cleanup
[15:45:15] <dgarr> jepler: i can test if/when you have a patch
[16:10:20] <jepler> dgarr: the newest version is on my branch. I think you want to: git checkout test; git reset --hard origin/master; git pull git://git.unpythonic.net/emc2-jepler.git parport
[16:10:33] <jepler> where 'test' is the branch you originally created to test this code
[16:11:19] <jepler> the second step throws away what you got from the first 'git pull' and later 'git apply', going back to a revision that you and I should have in common, and the final step gets the newest version of my changes
[16:14:10] <jepler> oops, you'll get some unwanted changes to the pluto driver when you do that, but presumably that won't affect you
[16:20:16] <dgarr> ok, starting now
[16:23:54] <cradek> jepler: got the wiring done for the front panel yesterday
[16:24:16] <cradek> it was an all-day affair but it's done well
[16:25:08] <jepler> cradek: what's next, the resolver?
[16:25:21] <cradek> yes, or more software work
[16:25:30] <jepler> cradek: any trouble with two hm2_pci?
[16:25:38] <cradek> actually I haven't rewired the wheel yet - I'll do that next
[16:25:44] <cradek> I hope to get one encoder input on the second card
[16:25:59] <cradek> a minor problem is that the old card because 1 and the new card 0 - I don't know if it can be controlled
[16:26:05] <cradek> but it was easy enough to fix up my hal
[16:26:25] <cradek> after reading the man page for hostmot2, I didn't have any trouble doing it.
[16:26:43] <cradek> (those are good manpages)
[16:27:47] <jepler> cradek: I think that the enumeration order is dependent on linux and the motherboard
[16:27:58] <jepler> you could probably have swapped pci slots to swap the order
[16:28:33] <cradek> in this case changing the hal files was much easier
[16:28:39] <cradek> lots of cables, not much space
[16:34:33] <dgarr> jepler: some progress!
http://www.panix.com/~dgarrett/stuff/parport_test_3.txt
[16:37:09] <jepler> dgarr: hm, so you got different behavior from port_addr=0 and port_addr=0x378?
[16:37:39] <dgarr> correct
[16:38:18] <jepler> in parport_common.h, please change each RTAPI_MSG_INFO to RTAPI_MSG_ERR, run again, and show me the dmesg for port_addr=0 and port_addr=0x378
[16:39:06] <jepler> (build and run again, I mean)
[16:40:19] <dgarr> moment
[16:47:35] <dgarr> jepler:
http://www.panix.com/~dgarrett/stuff/parport_test_4.txt
[16:50:39] <jepler> ah I bet I know what's going on
[16:50:44] <jepler> I overlooked something
[16:56:28] <jepler> try
http://pastebin.ca/1573012
[16:56:47] <jepler> after letting linux detect the port by number, you have to use the I/O address it reports
[16:56:51] <jepler> not I/O address 0
[17:03:32] <dgarr> nice work!
http://www.panix.com/~dgarrett/stuff/parport_test_5.txt
[17:04:13] <jepler> phew
[17:04:20] <jepler> thanks for your testing and patience
[17:05:56] <dgarr> np
[17:07:26] <dgarr> it's good to see some of the capabilities of git too
[17:08:20] <jepler> and it's got a lot of them
[17:09:52] <jepler> but this thing where I can organize my work with multiple commits, then share it with someone else relatively easily, go back and revise it a few times, and only then make it a part of the project's permanent history -- that's very powerful
[17:10:49] <dgarr> yes
[17:11:40] <jepler> when you did the 'git pull git://git.unpythonic.net', how long did that step take?
[17:12:15] <dgarr> just seconds i think, not sure
[17:13:48] <dgarr> now i want to : git checkout master, reply is fatal: Entry 'src/hal/drivers/hal_ppmc.c' not uptodate. Cannot merge.
[17:14:08] <dgarr> does this mean i should commit on the parport(=test) branch?
[17:14:12] <jepler> discard the change you made by patching that file: git checkout src/hal/drivers/hal_ppmc.c
[17:14:24] <jepler> or you can commit it, that would get you to the state where you can 'git checkout master' too
[17:16:26] <dgarr> ok -- that worked (had to checkout parport_common.h too)
[17:21:32] <jepler> that makes sense
[17:23:46] <dgarr> so i deduce one can not move between checkouts without making a commited state (duh)
[17:25:58] <jepler> right
[17:26:24] <jepler> often it's a mistake to do so
[17:27:14] <jepler> if you were working "in the wrong place", you can 'git stash' to save the changes and restore the working files to their checked-in state, then 'git checkout' to get to the appropriate branch, followed by 'git stash apply' to re-do the changes
[17:27:30] <jepler> or, in this case, you didn't care about the changes, so just use 'git checkout' to restore the files to their checked-in state
[17:31:14] <dgarr> thanks -- that's good to know (but maybe hard to remember if not used often:P
[17:40:47] <jepler> * jepler takes a deep breath and runs 'git push'
[17:41:23] <CIA-7> EMC: 03jepler 07master * rdc4c532aae2c 10/src/hal/drivers/ (pluto_common.h pluto_servo.comp pluto_step.comp): avoid using these names, as the kernel uses them
[17:41:23] <CIA-7> EMC: 03jepler 07master * r36e02a5c8ea6 10/src/hal/utils/comp.g: allow 'include <foo.h>' declarations
[17:41:24] <CIA-7> EMC: 03jepler 07master * r3c8d1c778909 10/src/rtapi/rtapi.h: fix confusing names
[17:41:25] <CIA-7> EMC: 03jepler 07master * r5b0ed0018404 10/src/hal/drivers/hal_ppmc.c: don't duplicate cleanup code
[17:41:27] <CIA-7> EMC: 03jepler 07master * raa6f6e25dc60 10/src/hal/drivers/ (pluto_common.h pluto_servo.comp pluto_step.comp): internally, extend counts to 64 bits
[17:41:30] <CIA-7> EMC: 03jepler 07master * r9b62710d4102 10/src/hal/drivers/ (hal_parport.c parport_common.h): Factor out parport registration code
[17:41:33] <CIA-7> EMC: 03jepler 07master * r92a81d88f3fd 10/src/hal/drivers/hal_ppmc.c: make ppmc use common parport code
[17:41:36] <CIA-7> EMC: 03jepler 07master * r4848543d6be8 10/src/hal/drivers/mesa-hostmot2/ (hm2_7i43.c hm2_7i43.h): make hm2_7i43 use common parport code
[17:41:39] <CIA-7> EMC: 03jepler 07master * rcd34a3a96f97 10/src/hal/drivers/ (pluto_common.h pluto_servo.comp pluto_step.comp): make pluto use common parport code
[17:41:44] <CIA-7> EMC: 03jepler 07master * rb7cee5f889f8 10/src/hal/ (hal.h hal_lib.c): new API returns component name
[17:41:49] <CIA-7> EMC: 03jepler 07master * rbf7d637827f6 10/debian/ (3 files in 3 dirs): do not disable the linux parport driver by default
[17:41:52] <CIA-7> EMC: 03jepler 07master * r296ff42f2088 10/docs/man/man3/ (rtapi_app_exit.3rtapi rtapi_app_main.3rtapi): fix typo
[17:41:55] <CIA-7> EMC: 03jepler 07master * re7bd83137d27 10/docs/man/man3/rtapi_app_exit.3rtapi: explain when rtapi_app_exit is not called
[18:06:05] <dgarr> jepler: so i updated master and these changes are running on my hw now
[18:10:37] <jepler> dgarr: let me know if you see any trouble
[18:11:12] <dgarr> sure, it seems fine
[18:12:02] <jepler> if it works at all, it's probably right
[18:21:22] <dgarr> jepler: i noticed i have a small patch for tooledit.tcl for review:
http://www.panix.com/~dgarrett/stuff/0001-use-name-tlo-instead-of-length-eliminate-global-q.patch
[18:41:55] <CIA-7> EMC: 03jepler 07master * r6dfbef02cbbc 10/src/emc/usr_intf/tooledit.tcl: use name tlo instead of length, eliminate global ::qid_private
[18:52:10] <cradek> jepler: you did it! yay!
[18:53:16] <cradek> ugh, ann arbor is 12 hours from here... guess it's about the same drive I did for NAMES
[18:55:13] <cradek> 18h for seb
[19:12:53] <alex_joni> guess it's closer for jmk
[19:14:19] <cradek> yeah, much
[19:14:23] <cradek> he'd win for once :-)
[19:16:19] <jepler> cradek: yeah, between dgarr and I, we have all the different kinds of parport hardware
[19:16:26] <jepler> so I think it's right
[19:16:31] <cradek> slick
[19:17:13] <jepler> and the compile farm hasn't given a peep, either, and that's a good sign
[19:18:39] <cradek> is it going?
[19:20:06] <jepler> yeah
[19:20:10] <jepler> I meant buildbot
[19:51:33] <alex_joni> good night all