Keil Hillman wrote: >> -----Original Message----- >> From: Sebastian Kuzminsky [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 16, 2008 2:21 AM >> To: Enhanced Machine Controller (EMC) >> Subject: Re: [Emc-users] hm2_7i43 hostmot2 loading - invalid cookie? >> >> This probably means the FPGA is not running the firmware the >> driver expects, or the communications between the driver and >> the 7i43 is getting garbled somehow (maybe bad cable). >> >> Please verify the integrity of the firmware file by running >> "md5sum SV8S.BIT", the output should be: >> >> 1380a9b6afa6f93d4d57e2d59a632efa SV8S.BIT > > md5sum's are good. > dbx:$ md5sum SV8S.BIT > 1380a9b6afa6f93d4d57e2d59a632efa SV8S.BIT > dbx:$ md5sum SVST4_4S.BIT > 6c20162fe16be55191119788a2bd4bf6 SVST4_4S.BIT
Well that's good. :-) >> How long is your parallel cable? Is it rated for IEEE 1284? >> Do you have any gender changers or adapters or anything in the path? >> > > I was afraid you'd ask about the cable. I questioned it at first and > this cable may very well be the problem. Here's the layout: > > Parport0 > (1) motherboard IDC26M header <-> IDC26F - standard PC 26 wire flat > ribbon cable - DB25F (external), standard PC parallel ribbon cable. > (2) Gender changer, you guessed it! > (3) same cable listed as 1 above, reversed to give IDC26F for connection > to 7i43. > I probed all 26 wires (end to end) on this combination with a Fluke DVM > for continuity. This doesnt sound unreasonable to me, but AFAIK there is no way to tell without looking at the signals with an oscilloscope... The fact that the FPGA accepts the firmware (since the INIT LED turns off) implies that the communication medium is not *totally* off... But when I was having EPP comm errors they would show up long after firmware loading, after successfully communicating with the FPGA for a long time. > Parport1 and parport2 were tested using the same cable arrangement, > however PCI parallel adapter parport1 is directly connected to card, not > ribbon cable to external mount. I would start with the assumption that at least one of the components of this cabling setup is defective. Try to build a new cable assembly which does not use any of the suspect components, and see if that fixes the problem. If the replacement cable assembly fixes it, immediately isolate the bad component of the old cable assembly and throw it in the trash can. ;-) > Sebastian, I found an archive post mentioning you had problems with > cables. What solved those problems? My EPP cabling setup much like your parport1, except with about a 6-foot EPP cable instead of a gender changer. I swapped the complete cabling assembly for another one and one that fixed it. I then isolated the EPP cable as the defective component (the DB25-to-IDC26 adapter at the 7i43 seems fine). >>> Also, tried to connect to 7i43 using tools from >>> mesa7i43-linux-utils-0.2.tar.bz2, but no luck either. Found >> the correct >>> ieee1284 and python debs. Couldn't figure out parport >> config stuff in >>> python scripts. >> Wow, I'd forgotten about that package. For it to work you >> need to have >> the Linux parport driver loaded, then when you make a mesa7i43 object >> you pass parport_id="parportX" to the constructor (where X is >> the number >> of the linux parport device). It defaults to parport0 if not >> specified. >> > > Thanks. Something like: > sudo modprobe parport parport_pc (with correct modparam's) ppdev First of all, i think this direction isn't all that useful. The python scripts were an early effort for me to understand 7i43 communications, they've been abandoned now that the RTAI/RTAPI device drivers are up and running. But we can probably make this work. You have installed RTAI and EMC2 from source on a Debian Sid system, right? Did you do the modutils config tweak to disable loading of parport_pc described here <http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Lenny_Compile_EMC2#Disabling_parallel_port_module>? If so, then modprobe will not load parport_pc, and you'll have to either undo the tweak or use insmod to load parport_pc. None of the Linux parport drivers should need any modparams. Once the drivers are loaded (watch dmesg to see that it finds the ports) we can start trying to get the programs to run. The reprogram-fpga.py script sends a BIT file to the FPGA. The cpld-reset script tries to talk to the CPLD to reset the board. All the other scripts work with the EPPIO firmware (none of the scripts talk to the HostMot2 firmware). The EPPIO firmware is available in the EMC2 CVS TRUNK in src/hal/drivers/mesa7i43-firmware/gpio, you'll want the "-2" version for your FPGA. > export parport_id="parport1" The way to specify the parport_id is to edit the python script you're running, for example for reprogram-fpga.py change something it to like this: m7i43 = mesa7i43(parport_id="parport1") > Do the *.py need to be compiled, I thought they were 0755 python > scripts? Sorry if this is trivial. The python programs dont need compiling, just edit and run like a shell script. But dont waste your time on mesa7i43-linux-utils until you get the cable fixed and comms work reliably with the hostmot2 and hm2_7i43 drivers ;-) -- Sebastian Kuzminsky Distances obtained as the speed of light multiplied by a cosmological time interval have no direct physical significance. <http://en.wikipedia.org/wiki/Observable_universe> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
