Back
[07:57:23] <tinkerer> cradek: oups sorry, yes reset is the init pin 16. it was a little bit late... ;)
[08:35:34] <cradek> tinkerer: do you have docs telling how to send the pluto firmware? I can't find anything useful online.
[08:36:21] <cradek> tinkerer: I'm trying to figure out whether pluto_clear_error_register() could be right
[08:36:38] <tinkerer> yes, somewhere i must search :)
[08:38:20] <jepler> cradek: pluto_clear_error_register is about clearing the EPP timeout bit, it is not related to programming the pluto
[08:38:23] <jepler> http://lxr.free-electrons.com/source/drivers/parport/parport_gsc.c#L65
[08:38:25] <jepler> it's pretty much copied from linux kernel
[08:38:57] <cradek> ah ok
[08:39:02] <cradek> but the double read is missing
[08:39:15] <jepler> that's true.
[08:39:28] <cradek> the docs I found that said STATUS is readonly must be wrong
[08:39:50] <jepler> I see they've cut&pasted it across the linux kernel tll
http://lxr.free-electrons.com/source/drivers/parport/parport_pc.c#L207
[08:42:10] <cradek> I wonder if I should pullup strobe still harder. it's still slow and noisy. maybe a little cap to remove the high frequency noise would be good, too
[08:42:31] <tinkerer> https://github.com/tinkercnc/spi-fpga-driver/blob/master/BBB/pluto_servo_bbbspi.comp#L419
[08:42:34] <cradek> I really should scope the working setup
[08:43:04] <tinkerer> here is some chunk i made for the beaglebone black
[08:45:44] <jepler> I don't think that knjn ever really documented the programming process; there's a pdf with the pinout
http://www.knjn.com/docs/KNJN%20FPGA%20Pluto-P%20board.pdf that I believe I related back to an ACEX1k document
[08:47:03] <tinkerer> jepler: yes you did. and i'm searching the ACEX1k document in my chaos....
[08:47:25] <jepler> one thing that occurs to me: how confident are you that you've separated "failure to program" from "failure to epp"? there's supposed to be a "ledblink.rbf" file somewhere. you could substitute it for the regular pluto firmware. you'll still get a failure to communicate via epp but at least you will know you uploaded the firmare configuration properly
[08:47:30] <jepler> bbl
[08:48:28] <tinkerer> yes, i've sent it to cradek
[08:52:39] <tinkerer> http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2015-05-09.html#17:06:50
[08:54:38] <tinkerer> a dejavu in the matrix...
[08:57:21] <tinkerer> maybe its a mothers day reset
[09:13:06] <tinkerer> cradek: i've sent you some code
[09:16:26] <tinkerer> dated from 2012 Sept.
[09:17:19] <pcw_home> no RC followed by Schmitt trigged on the clock?
[09:17:35] <cradek> jepler: pretty sure it's failure to program, because the led stays unchanged/dim
[09:18:25] <cradek> I have not changed the firmware - seems like the LED is enough to know whether it's programming
[09:19:54] <cradek> jepler: thanks, that pdf is also all I found, how sad that there's no documentation
[09:21:59] <jepler> I figured such an obvious idea would have occurred already
[09:22:45] <cradek> I think any EPP breakage in my sun parport would not even be relevant yet
[09:23:15] <cradek> pcw_home: no, it has pin 1 of the db25 wired directly to a fpga pin
[09:24:15] <pcw_home> Well, thats going to be pretty fussy about ports/cables
[09:24:34] <cradek> that's a very fair way to describe this device
[09:25:20] <cradek> it works on some ports and not others, with no discernable pattern
[09:25:56] <jepler> and I'd always assumed it was the EPP implementation but cradek's findings point towards a failure while trying to program it, which takes place in SPP mode
[09:26:01] <jepler> of course there could be 2 problem
[09:26:01] <jepler> s
[09:26:34] <pcw_home> at least in EPP mode you can fix the interface in the FPGA code
[09:27:12] <jepler> yes, and sometime within the last year I checked and the Altera SDK for the ACEX1k is still downloadable and can be used at no cost
[09:27:19] <jepler> I certainly don't have it set up anymore, though I think tinkerer does
[09:29:47] <cradek> I'm pleased to find that it's so overtly broken
[09:29:54] <tinkerer> hi dudes did you read my comments?
[09:30:18] <jepler> tinkerer: I haven't read everything but I've skimmed
[09:36:31] <tinkerer> about epp: there are some other problems with pci cards
[09:36:31] <tinkerer> http://www.asix.com.tw/faq.php?op=faqdetail&PItemID=130&FaqNoID=#523
[09:37:17] <tinkerer> in my case the nmos card works.
[09:37:31] <cradek> interesting
[09:37:39] <cradek> what chip exactly is on your working card?
[09:38:46] <tinkerer> MCS9805
[09:40:01] <tinkerer> but it works only with epp_wide = 0.
[09:40:56] <tinkerer> but your prob is the 1st quarter of the job
[09:41:40] <tinkerer> did you get my mail with the test code?
[09:43:52] <cradek> tinkerer: yes, thank you, but I think we're on the right track for finding a hardware problem. do you think there's something wrong with the linuxcnc pluto programming code?
[09:44:12] <tinkerer> and which firmware did you use? did you try the LEDblink.rbf
[09:45:07] <cradek> no (see above), because if pluto-servo programs correctly the LED will change from dim to something else
[09:46:47] <cradek> tinkerer: was it an accident that you changed your pluto derivative code to GPL3+? The code is GPL2+ in linuxcnc.
[09:48:36] <tinkerer> yes, but jeffs code resets itself if there is an error. nStatus of the fpga is internal connected with data5 of fpga and Init of the parport
[09:48:43] <tinkerer> which one?
[09:49:07] <cradek> this file:
https://github.com/tinkercnc/spi-fpga-driver/blob/master/BBB/pluto_servo_bbbspi.comp
[09:50:38] <tinkerer> maybe it was the github automatic
[09:51:42] <tinkerer> not intentional
[09:52:09] <cradek> cool, please fix
[09:52:22] <jepler> If the code is GPL3+ then the common view is that it cannot be loaded into the linux kernel which is GPLv2-only.
[09:57:37] <mozmck> I found and fixed some docs regarding emc2/linuxcnc - should I push to 2.7?
[09:58:15] <mozmck> They were in the Linux FAQ section of the Getting Started manual
[09:58:29] <cradek> absolutely - put them on the earliest relevant branch
[09:59:05] <seb_kuzminsky> if you put them in 2.6 they'll be hard (well, not really, just not automatic) to merge to 2.7
[09:59:12] <cradek> oh
[09:59:13] <seb_kuzminsky> because the getting-started docs got rototilled
[09:59:14] <mozmck> hmm, I don't know what that would be - maybe 2.6? I made the changes in 2.7
[09:59:30] <cradek> sounds like 2.7 is perfect :-)
[09:59:32] <mozmck> ok
[09:59:34] <seb_kuzminsky> heh
[10:03:08] <tinkerer> cradek: ahhh, it was the original file template :/
[10:03:13] <mozmck> I forgot to sign off the commit - can I add that now? or do I have to revert the commit and redo it?
[10:03:22] <cradek> git commit -s --amend
[10:03:55] <mozmck> thanks
[10:03:57] <KGB-linuxcnc> 03Moses McKnight 052.7 6713323 06linuxcnc 10docs/src/getting-started/Linux_FAQ.txt 10docs/src/getting-started/Linux_FAQ_es.txt Changed references and paths from emc2 to linuxcnc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6713323
[10:04:05] <seb_kuzminsky> mozmck: i forget to do that often, i added an alias 'git signoff' that does what cradek said
[10:04:49] <mozmck> If I use a gui like gitg to commit there is a check box and seeing that reminds me, but this one I did on the command line.
[10:15:48] <tinkerer> changed
[11:30:59] <tinkerer> cradek: i would suggest to try the ledblink test
[11:45:32] <jepler> altera doc on configuration:
https://www.altera.com/en_US/pdfs/literature/hb/cfg/cfg_cf51005.pdf
[11:46:16] <jepler> page 8-26 shows the waveform that should be used ("passive serial configuration using a microprocessor")
[11:48:40] <jepler> I don't think FPGA pin nCONFIG is even connected to the parallel port .. so how can the hal driver make sure the fpga is waiting for a configuration?
[11:49:07] <cradek> probably that's why if it fails to program once you have to unplug it
[11:49:20] <cradek> iirc you have to unpower it AND unplug it from the parport
[11:50:27] <cradek> isn't nCONFIG what's hooked to parport pin 16?
[11:50:34] <jepler> umm
[11:51:15] <jepler> it says that "nInit" is connected to FPGA pin number 84; it's also the EPP address strobe
[11:51:27] <cradek> 81
[11:51:29] <jepler> it being the KNJN pdf file
[11:51:38] <jepler> er oops, I jumped a line
[11:51:43] <jepler> you're right, it says pin 81 and is not used in EPP
[11:51:56] <jepler> that's the signal line that the hal driver tries to use to perform reset
[11:52:02] <jepler> servo.v:assign nConfig = epp_nReset; // 1'b1;
[11:52:51] <jepler> the fpga firmware continuously assigns epp_nReset (FPGA pin 81) nConfig (FPGA pin 49) to
[11:52:54] <jepler> err
[11:52:59] <jepler> assigns epp_nReset to nConfig
[11:54:44] <jepler> but that's a pretty iffy idea since how are you going to be sure you meet tCFG?
[11:58:22] <jepler> the real nCONFIG pin is pin 49, the pcb must connect pin 51 (a user I/O) to 49
[12:00:20] <jepler> if you had a sacrificial pluto board I wonder: cut the connection from FPGA pin 49 to 51 if you can, and connect parallel port pin 16 to fpga pin 51 (now you've got full PC control of nCONFIG so you can be sure you reset the damn thing)
[12:03:55] <jepler> parallel port pin 1 must be connected both to FPGA pin 90 (user I/O) and FPGA pin 75 (dedicated DCLK for configuration)
[12:04:30] <jepler> so similarly if you could cut the pin 75 connection while leaving the pin 90 connection, you could move FPGA configuration to parport pins 2 and 3 to get good bipolar driving
[12:04:57] <jepler> but no idea whether those traces are accessible or are under the FPGA package
[12:10:19] <cradek> fMAX on DCLK is 50 MHz. I bet that high frequency noise I see is madly clocking it
[12:12:03] <skunkworks> have you tried plugging the pluto directly into the port?
[12:12:42] <cradek> in past years yes - not recently - it would be hard mechanically to do that
[12:13:11] <skunkworks> I have had good luck with old Zip drive cables...
[12:13:45] <cradek> I tried several cables when I was blindly trying things, but now that I'm actually being methodical I'm using the cable that I know works with the other pc
[12:13:58] <skunkworks> ah
[12:14:19] <cradek> I should hook the other pc back up and scope at least DCLK and see what it looks like
[12:14:41] <cradek> I bet I'll find it's strong and square
[12:15:10] <pcw_home> what PP pin drives DCLK?
[12:15:31] <kwallace> Sorry if it has been asked before, but why fiddle with Pluto?
[12:15:34] <jepler> pcw_home: pin 1 I think
[12:15:50] <jepler> kwallace: his lathe's all put together based on pluto and now he wants to replace the PC
[12:15:55] <jepler> and not mess with the rest of the wiring
[12:16:16] <cradek> yeah it's even all mounted in a nice pretty box :-/
[12:16:29] <pcw_home> probably a bad choice since Strobe is often open drain
[12:16:32] <jepler> (this is a little sherline conversion, not the hnc)
[12:16:54] <jepler> pcw_home: yes and it certainly is on the SUN parport cradek is now using
[12:17:00] <kwallace> At this point, it seems that redoing the hardware would have been easier.
[12:17:00] <cradek> and this has been a thorn in our sides for 10 years and it would be nice to actually figure it out
[12:17:22] <pcw_home> add a board with a 74HCT14...
[12:17:25] <cradek> kwallace: yes that is apparent and true, but here we are
[12:17:50] <cradek> pcw_home: did you see the scope pics?
[12:17:56] <pcw_home> no
[12:18:03] <cradek> http://timeguy.com/cradek-files/emc/pluto-pin1top-pin2bottom.jpg
[12:18:15] <cradek> as found, clock on top, data on bottom
[12:18:30] <cradek> clock line with added 2k2 pullup to +5:
http://timeguy.com/cradek-files/emc/pluto-pin1clock-2k2pullup+5.jpg
[12:19:09] <cradek> more detail of as-found clock line:
http://timeguy.com/cradek-files/emc/pluto-pin1clock.jpg
[12:19:10] <pcw_home> umm since its clocked on the rising edge that probably a lose...
[12:19:21] <cradek> yeah absolutely
[12:19:29] <pcw_home> 300 Ohm pullup to 3.3V?
[12:19:37] <cradek> and if the noise is real (I think it is) it's probably clocking many times for each
[12:19:54] <Tom_itx> pcw_home did you catch that message in main channel about a mesa card causing the pc not to boot?
[12:19:55] <kwallace> I'm still using a Pluto to generate fast PWM for the spindle VFD on my Shizuoka mill.
[12:19:55] <cradek> yeah 2k2 was too big, I'll try much smaller
[12:20:42] <cradek> +5 is available nearby so I used that
[12:20:51] <pcw_home> best would be PP pin 1 usec RC --> 74HCT14 two inverters --> DCLK
[12:20:55] <jepler> I haven't found a spec for rise/fall time of DCLK but regular FPGA clocks require tR/tF <= 5ns
[12:21:37] <cradek> wonder if I can find a '14 at home
[12:22:30] <Tom_itx> pcw_home, starting 22:55:53
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc/2015-05-11.html
[12:25:26] <pcw_home> Tom_itx: Oooh backwards, thats not good (I wonder where +12 and -12V end up)
[12:27:06] <Tom_itx> meh, that's covered under warranty !
[12:29:29] <Tom_itx> that limit on the pid fixed the runaway btw
[12:29:34] <Tom_itx> thanks
[12:29:39] <pcw_home> I wiped out a MB with my 6I24 proto 1.2V to 3.3V short fried PCIE socket and nice glowing crater in FPGA
[12:29:59] <Tom_itx> brought the I numbers up a bit more and it seems to work ok now
[12:30:14] <jepler> holy cow, the PCI connector itself is not keyed?
[12:30:21] <Tom_itx> it should be
[12:30:37] <seb_kuzminsky> are we doing embarrassing electrical stories? I plugged a 12V power supply into a usb hub and couldn't figure out why the keyboard & mouse weren't working, and kept trying other keyboards & mice...
[12:30:40] <pcw_home> Nope not for universal PCI cards (3.3 or 5V)
[12:30:55] <cradek> bzzt bzzt bztt nope not this one either bzzt bzzt nope bzzt
[12:31:19] <pcw_home> That s like people testing 1/16 A fuses on old Multimeters...
[12:31:31] <Tom_itx> i hope i don't add to the list... about to go out and hook the control back up to the mill today
[12:31:42] <pcw_home> why are are all open?
[12:31:55] <jepler> 12/13 is the notch for 3.3v capable, 50/51 is the notch for 5v capable, out of 62 total per sides. so, yep, same distance from each respective end
[12:32:05] <jepler> how did that get through the standardization process?
[13:04:27] <seb_kuzminsky> ebo's question about 2.8 reminds me: anyone else want to be RM for 2.8?
[13:05:43] <cradek> I think pcw_home should do it
[13:13:43] <mozmck> I'm tempted to offer, but I don't think I know enough, and probably don't have the time.
[13:14:21] <cradek> I would be happy to help you if you encounter any shaky spots
[13:14:22] <seb_kuzminsky> thanks mozmck... there's definitely some knowledge & time requirement
[13:15:00] <mozmck> what all is involved?
[13:15:11] <seb_kuzminsky> i'd be happy to keep running the buildbot & helping out with packaging etc
[13:15:54] <cradek> the hard part is saying yes or no when people want to add things to the branch you're managing. sometimes it's right to say no, if you think the stability risk is too high, and that's often hard to do
[13:16:15] <seb_kuzminsky> it's mostly paying attention to bugs & issues, deciding when the branch is "good enough" to release, updating the debian/changelog, moving buildbot debs into the wlo deb archive, and sending out announcemnt emails & updating webpages
[13:16:17] <cradek> other than that, you decide when to release, and that process is pretty easy after all of seb's work
[13:16:51] <cradek> yes you have to construct the changelog. I usually do that by going through the commits and understanding them. I bet you keep up well enough already to be fine at that.
[13:17:01] <mozmck> I see. That might not be too hard.
[13:17:15] <seb_kuzminsky> here's the checklist i try to follow:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList
[13:17:17] <mozmck> I try to. I fall behind some for work distractions.
[13:17:31] <seb_kuzminsky> heh yeah, we all fall behind from time to time
[13:17:40] <seb_kuzminsky> mouths to feed, lives to live, that kind of thing
[13:18:14] <mozmck> I'm finishing up a plasma table in my shop, and will be testing linuxcnc on it a lot soon.
[13:18:57] <mozmck> Let me look at that stuff and think on it. I might volunteer, especially if no one else steps up.
[13:19:08] <seb_kuzminsky> cool
[13:19:25] <seb_kuzminsky> if you like we could do the next 2.6 or 2.7~pre release together and you could see what's involved
[13:19:48] <mozmck> thanks! that might help
[13:19:53] <cradek> awesome
[13:20:31] <seb_kuzminsky> yay :-)
[13:41:36] <jepler> I'm also available to help the RM if it's needed
[13:55:44] <mozmck> thanks, I would certainly ask for help!
[13:56:19] <mozmck> seb_kuzminsky: just ping me or email when you are ready to do the next (pre)release
[13:56:39] <mozmck> back to the shop - bbl
[14:16:41] <tinkerer> pluto-dudes:
http://www.fpga4fun.com/forum/viewtopic.php?t=1150
[15:56:05] <skunkworks> zlog
[23:11:09] <skunksleep> zlog
