cradek_ is now known as cradek
mozmck1 is now known as mozmck
I made a simple latch hal component that may be useful to others. If I were to add it to emc2 in src/hal/components/ would it get built automatically?
mozmck: if it's a .comp, you can just drop it in that directory and it will get built
anyone around who has ppmc hardware handy? I'm working on some improvements to the parport-related infrastructure that affect ppmc/usc, but I don't have one to test..
actually, if you have 7i43, pluto, or plain old parport your testing would be helpful too
git checkout -b parport master; git pull git://git.unpythonic.net/emc2-jepler.git parport
after building, run and test that your parport-attached device still works. Then 'sudo modprobe -i parport_pc'. Run and test a second time that your parport-attached device still works.
then change your configuration so that where a parport I/O address such as 0x378 is shown, you use a small number like 0, 1, 2 to mean the device linux detects as /dev/lp0, lp1, and so on
I hooked up a Modbus equipped PLC to EMC2 and have it passing 5 words of info back and forth.
I found that when I run Modbus while doing a read holding registers function on 5 words - things work great
When I add a write function to send 5 holding registers - I get periodic time outs. (Using function 16 write multiple holding registers)
If I remove the write function that sends the 5 holding registers and then add 5 individual write holding register functions (should be function 6), I do not get any Modbus errors.
The errors are flagged both on the PC end via the Modbus error box popping up and on the PLC module as it says a timeout has occured.
I have used this same PLC module with different software to write and read these same 10 holding registers without incident.
So there may be a bug in the utilization of Modbus function 16 - write multiple holding registers?
Is this a known bug? Where are the known bugs listed? Is this the proper way to report a bug??
If someone is familar with the code around the Modbus programming - I could run this serial link though some comm analyzer software and find out exactly where things are falling down.
Dave911: just a guess but I'll bet the individual write commands fit in the PC UARTS FIFO,
so the command is sent in one contiguous packet and the 3.5 char Modbus timeout can't bite
but with the 5 commands strung together the xmit gets interrupted by some real time task and
you get a > 3.5 char delay
What baud rate are you using? a lower baud rate may help
I'm using 38400 baud.
I tried it with lower baud rates - same results
I think there is a bug in the code.
Well... wait. No I didn't try this with lower baud rates. I can try it at lower baud rates and report back if that would help.
I doubt that it is a real time task interference issue. The modbus flat out flies with individual writes and a group read of 5 words. A group write of 5 words is very similar to a group read as far as message length.
The group read of 5 words "never" faults out.
The group write of 5 words faults out constantly. It is very consistent. Not once in a while.
A group read would fit in the FIFO (since theres no data included) , a group write would not...
Group write is 9 + 2X number of 16 bit params = 29 bytes for 5 params
Group read is always 8 bytes
Only takes a 1.5 char delay in transmit packet to violate spec, This is only about 500 uSec at 38400 baud
Easy to meet spec when entire packet can be loaded into FIFO, otherwise tough, especially because while 16C550 UARTS
have receive FIFO triggers, there is no corresponding logic for transmit.
jepler: parport branch test: http://www.panix.com/~dgarrett/stuff/parport_test.tst
(oops not 29 but 19 bytes for 5word group write, still >16 FIFO size)
dgarr: thanks, looking now
dgarr: that Module.symvers thing is unrelated..
dgarr: hmph, looks like ppmc needs more work; "0" means the first port found by linux, but ppmc rejects it..
dgarr: do you have a version of rtai-modules-2.6.24-16-rtai other than 3.6.1-linuxcnc.4 ?
$ dpkg-query -S /usr/realtime-2.6.24-16-rtai/modules/Module.symvers
$ dpkg -s rtai-modules-2.6.24-16-rtai | grep Version
jepler: i've turned that pc off but the pc in the house is Version: 3.6-linuxcnc.2 so that is probably the version i have everywhere
dgarr: I rebased the 'parport' branch to get rid of the module-building differences, so you can re-make your test branch again and test if port 0 is now accepted, or you can just apply http://emergent.unpy.net/files/sandbox/0001-0-means-linux-detected-parport-0.patch
jepler: do i pull again like this?: git pull git://git.unpythonic.net/emc2-jepler.git parport
dgarr: that *may* refuse, because I rebased my branch (altered the part of history you already had from me)
dgarr: to throw away the old 'test' branch and start anew: git checkout master; git branch -D test; git checkout -b test; git pull ...
or I suppose you could (on branch test): git reset --hard master; git pull ...
that has the advantage of being shorter
as an infrequent user, the git terms are like greek to me, i'll try to test this evening PDT
I appreciate it
* alex_joni is back
I was a week in germany
alex_joni: welcome home
thx .. it's nice to be home
good night all