Back
[01:35:31] <cradek_> cradek_ is now known as cradek
[02:12:13] <mozmck1> mozmck1 is now known as mozmck
[04:02:14] <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?
[14:19:32] <cradek> mozmck: if it's a .comp, you can just drop it in that directory and it will get built
[17:38:18] <jepler> 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..
[17:40:43] <jepler> actually, if you have 7i43, pluto, or plain old parport your testing would be helpful too
[17:41:03] <jepler> git checkout -b parport master; git pull git://git.unpythonic.net/emc2-jepler.git parport
[17:41:37] <jepler> 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.
[17:42:30] <jepler> 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
[19:16:35] <Dave911> Modbus questiono/observation.....
[19:16:36] <Dave911> I hooked up a Modbus equipped PLC to EMC2 and have it passing 5 words of info back and forth.
[19:16:38] <Dave911> I found that when I run Modbus while doing a read holding registers function on 5 words - things work great
[19:16:39] <Dave911> When I add a write function to send 5 holding registers - I get periodic time outs. (Using function 16 write multiple holding registers)
[19:16:41] <Dave911> 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.
[19:16:43] <Dave911> 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.
[19:16:45] <Dave911> I have used this same PLC module with different software to write and read these same 10 holding registers without incident.
[19:16:46] <Dave911> So there may be a bug in the utilization of Modbus function 16 - write multiple holding registers?
[19:16:48] <Dave911> Is this a known bug? Where are the known bugs listed? Is this the proper way to report a bug??
[19:16:49] <Dave911> 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.
[19:16:51] <Dave911>
[19:16:53] <Dave911>
[19:42:36] <pcw_home> Dave911: just a guess but I'll bet the individual write commands fit in the PC UARTS FIFO,
[19:42:38] <pcw_home> so the command is sent in one contiguous packet and the 3.5 char Modbus timeout can't bite
[19:42:39] <pcw_home> but with the 5 commands strung together the xmit gets interrupted by some real time task and
[19:42:41] <pcw_home> you get a > 3.5 char delay
[19:42:42] <pcw_home> What baud rate are you using? a lower baud rate may help
[20:50:02] <Dave911> I'm using 38400 baud.
[20:50:37] <Dave911> I tried it with lower baud rates - same results
[20:51:18] <Dave911> I think there is a bug in the code.
[20:55:10] <Dave911> 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.
[20:55:13] <Dave911> 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.
[20:55:14] <Dave911> The group read of 5 words "never" faults out.
[20:55:16] <Dave911> The group write of 5 words faults out constantly. It is very consistent. Not once in a while.
[20:56:48] <pcw_home> A group read would fit in the FIFO (since theres no data included) , a group write would not...
[21:05:38] <pcw_home> Group write is 9 + 2X number of 16 bit params = 29 bytes for 5 params
[21:05:39] <pcw_home> Group read is always 8 bytes
[21:05:41] <pcw_home> (RTU)
[21:16:04] <pcw_home> Only takes a 1.5 char delay in transmit packet to violate spec, This is only about 500 uSec at 38400 baud
[21:16:05] <pcw_home> Easy to meet spec when entire packet can be loaded into FIFO, otherwise tough, especially because while 16C550 UARTS
[21:16:07] <pcw_home> have receive FIFO triggers, there is no corresponding logic for transmit.
[21:27:48] <dgarr> jepler: parport branch test:
http://www.panix.com/~dgarrett/stuff/parport_test.tst
[21:44:36] <pcw_home> (oops not 29 but 19 bytes for 5word group write, still >16 FIFO size)
[22:00:48] <jepler> dgarr: thanks, looking now
[22:01:00] <jepler> dgarr: that Module.symvers thing is unrelated..
[22:02:16] <jepler> dgarr: hmph, looks like ppmc needs more work; "0" means the first port found by linux, but ppmc rejects it..
[22:03:39] <jepler> dgarr: do you have a version of rtai-modules-2.6.24-16-rtai other than 3.6.1-linuxcnc.4 ?
[22:05:09] <jepler> $ dpkg-query -S /usr/realtime-2.6.24-16-rtai/modules/Module.symvers
[22:05:09] <jepler> rtai-modules-2.6.24-16-rtai: /usr/realtime-2.6.24-16-rtai/modules/Module.symvers
[22:05:12] <jepler> $ dpkg -s rtai-modules-2.6.24-16-rtai | grep Version
[22:05:15] <jepler> Version: 3.6.1-linuxcnc.4
[22:13:25] <dgarr> 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
[22:18:49] <jepler> dgarr: OK
[22:20:17] <jepler> 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
[22:22:56] <dgarr> jepler: do i pull again like this?: git pull git://git.unpythonic.net/emc2-jepler.git parport
[22:24:40] <jepler> dgarr: that *may* refuse, because I rebased my branch (altered the part of history you already had from me)
[22:25:17] <jepler> dgarr: to throw away the old 'test' branch and start anew: git checkout master; git branch -D test; git checkout -b test; git pull ...
[22:25:53] <jepler> or I suppose you could (on branch test): git reset --hard master; git pull ...
[22:25:58] <jepler> that has the advantage of being shorter
[22:27:28] <dgarr> as an infrequent user, the git terms are like greek to me, i'll try to test this evening PDT
[22:29:17] <jepler> I appreciate it
[22:35:15] <alex_joni> hi guys
[22:36:42] <jepler> hi alex_joni
[22:38:40] <alex_joni> * alex_joni is back
[22:38:44] <alex_joni> I was a week in germany
[23:07:53] <jepler> alex_joni: welcome home
[23:17:02] <alex_joni> thx .. it's nice to be home
[23:20:00] <alex_joni> good night all
[23:20:24] <jepler> night