jepler: nojoy http://www.panix.com/~dgarrett/stuff/parport_test_2.txt
hm, you took down the first set of results? drat.
no, but fixed a typo in name, see: http://www.panix.com/~dgarrett/stuff/parport_test.txt
so it's much worse with the patch than without
the last patch, anyway
hm, here's some "duh" the code I wrote, but I don't understand how it would relate to the detection failures
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 ..
>>(oops not 29 but 19 bytes for 5word group write, still >16 FIFO size)
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.
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.
there's a modbus.c/h in src/hal/user_comps
Don't know if that's what you need for sure...
jepler: no solution but some observations: http://www.panix.com/~dgarrett/stuff/notes_1.txt
Easy way to verify if its a timing issue is to lower baud rate, if problem goes away, its a timing issue
modbus.c users the standard linux serial port driver I wonder if that it gives any guarantees about
delays in xmit data stream....
dgarr: thanks for the noes, reading them now
dgarr: the switched size/base call in parport_common is the duh I found
but I hadn't figured out that it was the function declarations that were causing me to be so very confused
Dave911 & others: there was an modbus protocol implementation error discovered by some german guy
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
not sure if that's readable for people not subscribed there
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.
FWIW, The Forum is pretty hard to find for a Newbie. Perhaps the link could be made more obvious on the support page ??
aha, there were two places to check for the "unspecified" parport address
and a bug in the cleanup
jepler: i can test if/when you have a patch
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
where 'test' is the branch you originally created to test this code
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
oops, you'll get some unwanted changes to the pluto driver when you do that, but presumably that won't affect you
ok, starting now
jepler: got the wiring done for the front panel yesterday
it was an all-day affair but it's done well
cradek: what's next, the resolver?
yes, or more software work
cradek: any trouble with two hm2_pci?
actually I haven't rewired the wheel yet - I'll do that next
I hope to get one encoder input on the second card
a minor problem is that the old card because 1 and the new card 0 - I don't know if it can be controlled
but it was easy enough to fix up my hal
after reading the man page for hostmot2, I didn't have any trouble doing it.
(those are good manpages)
cradek: I think that the enumeration order is dependent on linux and the motherboard
you could probably have swapped pci slots to swap the order
in this case changing the hal files was much easier
lots of cables, not much space
jepler: some progress! http://www.panix.com/~dgarrett/stuff/parport_test_3.txt
dgarr: hm, so you got different behavior from port_addr=0 and port_addr=0x378?
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
(build and run again, I mean)
ah I bet I know what's going on
I overlooked something
after letting linux detect the port by number, you have to use the I/O address it reports
not I/O address 0
nice work! http://www.panix.com/~dgarrett/stuff/parport_test_5.txt
thanks for your testing and patience
it's good to see some of the capabilities of git too
and it's got a lot of them
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
when you did the 'git pull git://git.unpythonic.net', how long did that step take?
just seconds i think, not sure
now i want to : git checkout master, reply is fatal: Entry 'src/hal/drivers/hal_ppmc.c' not uptodate. Cannot merge.
does this mean i should commit on the parport(=test) branch?
discard the change you made by patching that file: git checkout src/hal/drivers/hal_ppmc.c
or you can commit it, that would get you to the state where you can 'git checkout master' too
ok -- that worked (had to checkout parport_common.h too)
that makes sense
so i deduce one can not move between checkouts without making a commited state (duh)
often it's a mistake to do so
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
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
thanks -- that's good to know (but maybe hard to remember if not used often:P
* jepler takes a deep breath and runs 'git push'
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
EMC: 03jepler 07master * r36e02a5c8ea6 10/src/hal/utils/comp.g: allow 'include <foo.h>' declarations
EMC: 03jepler 07master * r3c8d1c778909 10/src/rtapi/rtapi.h: fix confusing names
EMC: 03jepler 07master * r5b0ed0018404 10/src/hal/drivers/hal_ppmc.c: don't duplicate cleanup code
EMC: 03jepler 07master * raa6f6e25dc60 10/src/hal/drivers/ (pluto_common.h pluto_servo.comp pluto_step.comp): internally, extend counts to 64 bits
EMC: 03jepler 07master * r9b62710d4102 10/src/hal/drivers/ (hal_parport.c parport_common.h): Factor out parport registration code
EMC: 03jepler 07master * r92a81d88f3fd 10/src/hal/drivers/hal_ppmc.c: make ppmc use common parport code
EMC: 03jepler 07master * r4848543d6be8 10/src/hal/drivers/mesa-hostmot2/ (hm2_7i43.c hm2_7i43.h): make hm2_7i43 use common parport code
EMC: 03jepler 07master * rcd34a3a96f97 10/src/hal/drivers/ (pluto_common.h pluto_servo.comp pluto_step.comp): make pluto use common parport code
EMC: 03jepler 07master * rb7cee5f889f8 10/src/hal/ (hal.h hal_lib.c): new API returns component name
EMC: 03jepler 07master * rbf7d637827f6 10/debian/ (3 files in 3 dirs): do not disable the linux parport driver by default
EMC: 03jepler 07master * r296ff42f2088 10/docs/man/man3/ (rtapi_app_exit.3rtapi rtapi_app_main.3rtapi): fix typo
EMC: 03jepler 07master * re7bd83137d27 10/docs/man/man3/rtapi_app_exit.3rtapi: explain when rtapi_app_exit is not called
jepler: so i updated master and these changes are running on my hw now
dgarr: let me know if you see any trouble
sure, it seems fine
if it works at all, it's probably right
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
EMC: 03jepler 07master * r6dfbef02cbbc 10/src/emc/usr_intf/tooledit.tcl: use name tlo instead of length, eliminate global ::qid_private
jepler: you did it! yay!
ugh, ann arbor is 12 hours from here... guess it's about the same drive I did for NAMES
18h for seb
guess it's closer for jmk
he'd win for once :-)
cradek: yeah, between dgarr and I, we have all the different kinds of parport hardware
so I think it's right
and the compile farm hasn't given a peep, either, and that's a good sign
is it going?
I meant buildbot
good night all