Back
[08:21:59] <JT-JA> fresh install of LinuxMint 17.3 and following the manual I did sudo apt-get update sudo apt-get dist-upgrade and sudo apt-get install linux-image-rt-686-pae but got this error E: Unable to locate package linux-image-rt-686-pae
[08:29:06] <JT-JA> I guess I need to follow my instructions
http://pastebin.ubuntu.com/16047896/
[09:28:45] <skunkworks> yikes
[09:28:46] <skunkworks> http://www.machsupport.com/forum/index.php/topic,32401.msg225458.html#msg225458
[09:56:30] <cradek> oops
[09:56:56] <skunkworks> cradek, did you see my middle of the night question?
[09:57:02] <cradek> no
[09:57:46] <cradek> now I see it :-)
[09:59:27] <cradek> if you set ff1=1 and I=0 and plot the ferror, won't you see it directly? then I think if you turn the gain knob on the amp you can zero the ferror
[10:01:58] <skunkworks> but what if I didn't want to adjust the amps - but the output scale. How would I work backwards?
[10:02:04] <skunkworks> or shouldn't I.
[10:02:17] <cradek> oh hmm
[10:03:19] <cradek> I think the output scale should be set so you use most of the 10v (say 9?) for your rapids
[10:03:55] <cradek> seems like the amps would already be set up close to that
[10:04:54] <cradek> either way, if you have just ff1=1 and no I, I think you'll see ferror and you can adjust gain (at the dac or amp) to zero it
[10:05:03] <cradek> (ferror proportional to velocity)
[10:05:59] <skunkworks> which is kinda what I did. Assuming it is linear .1v is 1ips about - I have my output scale set to 10
[10:06:37] <skunkworks> cradek, did you see
http://electronicsam.com/images/matsuura/followingerror.png
[10:06:44] <cradek> how much of the 10v do you use at rapid then?
[10:06:45] <skunkworks> that is with just P and FF1 ;)
[10:06:48] <pcw_home> you can do it backwards by setting FF1 to 1 and adjusting PWM scale
[10:07:14] <cradek> ah nice
[10:07:42] <skunkworks> I think it should tune well - the way it looks
[10:07:46] <cradek> if you get the scale closer you will see that fast dithering slow and maybe even stop
[10:08:15] <cradek> but yeah that looks great
[10:08:16] <skunkworks> I am figuring on tuning to 500ipm
[10:08:39] <skunkworks> (according to the little playing it should go to 600
[10:08:49] <cradek> velocity mode amps are great, aren't they
[10:08:56] <skunkworks> they are. even old ones.
[10:08:57] <cradek> it's nice when they're matched and tuned to the machine already
[10:09:22] <skunkworks> what should the max pid output be set to then?
[10:09:33] <cradek> I had to mess with mine a lot (replaced 2 of them)
[10:09:45] <cradek> many mysterious jumpers and soldered capacitors
[10:10:38] <cradek> I guess pid maxoutput should be a little more than what you get at rapid?
[10:11:04] <cradek> then it'll saturate if something goes wrong (you could tie the saturated output to amp-fault)
[10:11:50] <cradek> the amps also have a speed limit (at the tach input) and they'll fault with the tach error LED on if you get going too fast
[10:12:10] <cradek> which is nice...
[10:13:36] <skunkworks> dad has a few extra off ebay. we got the machine cheap because we think they where chasing their tail trying to fix a drive issue
[10:13:57] <cradek> heh did you find the real problem already?
[10:14:38] <skunkworks> we think the real problem was an open megohm resistor in the over current circuit of the drive.
[10:15:13] <cradek> yay
[10:15:51] <skunkworks> I don't know how dad found it ;)
[10:17:52] <skunkworks> not too messy ;)
[10:17:53] <skunkworks> http://electronicsam.com/images/matsuura/20160423_155545.jpg
[10:18:02] <skunkworks> those cables are nice
[10:18:52] <cradek> wow, stout
[10:45:35] <pcw_home> Hmm customer trying to get 700 IPM from stepmotors with 14 TPI leadscrew....
[10:45:50] <skunkworks> that probably isn't going to happen...
[10:47:01] <archivist> managing unrealistic expectations is hard
[10:47:04] <pcw_home> asking you to change the tuning (its closed loop) to fix it
[10:47:59] <pcw_home> it does get to ~300 IPM before is goes bad (4200 RPM!)
[10:48:09] <skunkworks> show him the stepper motor rpm/torque curve?
[10:49:18] <pcw_home> I just explained that stepmotor have great low speed torque but that it drops rapidly at higher speeds
[10:49:28] <pcw_home> stepmotors
[10:51:10] <pcw_home> 700 IPM is probably possible with a plasma system with relatively coarse gearing
[10:54:17] <skunkworks> Next to hook up the spindle drive analog
[11:00:11] <skunkworks> the 7i80 hasn't had an issue at all
[11:00:26] <skunkworks> (well - that wasn't caused by me)
[11:03:49] <skunkworks> pcw_home, has something changed with the 7i80 vs the 5i20 in regards to the opto22 boards? I remember having to set the gpio to open collector for the 5i20 - the 7i80 doesn't seem to care. (the led would glow very dimly if open collector wasn't set)
[11:10:13] <pcw_home> The bus switches on the Spartan3 boards allow 5V VOut even in push-pull mode
[11:10:55] <pcw_home> ( when jumpered for 5V tolerance mode )
[11:11:19] <pcw_home> Spartan3 and > I mean
[11:13:44] <pcw_home> The 5I20 outputs (Spartan2) are direct which means that output pins will be at 3.3V when high (which will turn +5V referenced LEDs on slightly )
[11:50:56] <skunkworks> ah
[11:50:58] <skunkworks> thanks!
[11:55:12] <pcw_home> The FPGA cards with the bus switches also seem more resistant to damage (many more 5i20s back for repair than newer cards)
[11:55:14] <pcw_home> and in most cases if damaged, the bus switch is damaged, not the FPGA
[12:00:36] <skunkworks> Cool - the 2 5i20 cards in the K&T have been rock solid. all of the i/o goes through opto22 though
[12:00:58] <skunkworks> (other than the drive interfaces)
[12:01:03] <jepler> I have a damaged card on which I should test that theory. A couple years ago, we blew up one of peter's little DC servo amps with back EMF; later I noticed that some of the outputs of the fpga board didn't work right either
[12:08:58] <skunkworks> wow - dad has been going to town
[12:08:59] <skunkworks> http://electronicsam.com/images/matsuura/DSC_7638.JPG
[12:10:16] <skunkworks> should have taken a before picture. There was a double layer terminal strip on the left side
[13:54:32] <JT-Shop> yea my plasma will go 600 IPM on Nema 23 steppers
[13:54:51] <JT-Shop> I have it capped at 500 as there is no cut speed above that
[14:04:32] <jepler> gross: > If you don't have a multimeter, set up a quick circle cut or similar that you can cut multiple times in a piece of waste material. Use a generous step down because we're trying to see when the machine misses steps. After each run, turn your current adjustments down bit by bit (CCW) - maybe 5 minutes on a clock dial each time. You should start seeing missed steps do to insufficient current.
[14:04:38] <jepler> Next, start working the other way turning the current up slightly (CW). At some point you should start seeing missed steps due to thermal shutdown. Back off slightly from this point, and you have a decent setting.[8]
[14:07:29] <PCW> what if you start seeing missed steps due to fire?
[14:16:19] <skunkworks> what magical stepping controller is this?
[14:21:16] <jepler> some reprap-class dingus
[14:23:53] <jepler> thermal shutdown circuitry is a part of a lot of the low end microstepping drivers such as A3967
[14:24:12] <jepler> I suppose it's good if they're designed to just ruin the work, not catch fire or melt their internal bonding wires
[14:25:07] <skunkworks> is this a realtime delay cause this?
[14:25:11] <skunkworks> http://pastebin.com/bvjeGds6
[14:25:21] <skunkworks> or is it a communication error?
[14:25:48] <jepler> I think that's a communication error first
[14:25:52] <skunkworks> (this is the HP i5 that had been running until today sometime.
[14:26:01] <skunkworks> ok. odd
[14:26:11] <skunkworks> maybe someone wiggled it
[14:26:22] <jepler> it's known that when a read request or read response packet is lost, the driver goes south and you have to restart linuxcnc
[14:26:38] <jepler> it's on my list of hm2_eth items to improve that
[14:27:08] <skunkworks> The matsuura (7i90) has been running for weeks and weeks with no issue.
[14:27:11] <jepler> There's a WIP branch relative to master that improves things a bit:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/jepler/master/eth-packet-loss
[14:27:17] <skunkworks> *7i80
[14:27:57] <skunkworks> I can certainly test it on this machine
[14:28:44] <jepler> if your lost packet rate is on the order of 1/month I'm not sure it'll be the most useful test :)
[14:30:19] <skunkworks> heh - but it can run for another month.
[14:33:37] <jepler> anyway all the hard part of that little project remains to be done
[14:34:06] <jepler> the next easy step is to make the timeout configurable, and add an output to indicate when a failed read occurs (but without faulting the machine right away)
[14:34:28] <jepler> the hard step is figuring out how to make each different subsystem of hostmot2 work right in the event of a lost read or write
[14:35:01] <jepler> .. for instance, how you detect and what you do to recover from a lost write to the index-enable bit in an encoder
[14:36:29] <skunkworks> I am sure there are things not even thought about...
[14:46:41] <jepler> I think it's the most nebulous problem I've worked on so far where the hostmot2 driver is concerned
[15:08:28] <PCW> Sometime I think index enable should always be set
[15:09:43] <PCW> This also allows encoder sanity checking
[15:47:00] <seb_kuzminsky> jepler: i attempted to add something like that for the epp boards, way back when
[15:47:43] <seb_kuzminsky> the llio struct has an io_error hal pin
[15:47:59] <seb_kuzminsky> it gets set when the hm2_7i43 driver detects epp timeout
[15:48:06] <seb_kuzminsky> when set, all communication with the board is stopped
[15:48:16] <seb_kuzminsky> the user has to clear it in hal
[15:48:47] <seb_kuzminsky> then the hm2 driver force-writes all modules to sync their state up with the driver, and then normal communications start back up
[15:48:53] <seb_kuzminsky> might that work for the hm2_eth boards?
[16:09:59] <jepler> seb_kuzminsky: I should look closely at that
[16:10:15] <jepler> seb_kuzminsky: in the case of ethernet, we want to continue (not stop) after a lost packet
[16:10:45] <jepler> but using force-write after a detected packet loss until the next success occasion sounds like a great idea; I'll study how to do that
[16:10:50] <jepler> thanks!
[16:15:06] <jepler> after a *single* lost packet. There'll need to be some sort of count up on error / count down on success / error on reaching threshold system for these detected ethernet errors
[16:19:12] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/trt_doc_test c1ce971 06linuxcnc 10docs/src/Submakefile 10docs/src/motion/5-axis-kinematics.txt docs/src/Submakefile use asciidoc -a latexmath * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c1ce971
[17:48:18] <seb_kuzminsky> github gets an F in Ethics from the FSF:
https://www.gnu.org/software/repo-criteria-evaluation.html
[19:10:03] <cradek> I have trouble getting worked up over the javascript thing.
[19:15:40] <andypugh> I feel that there may be more pressing ethical concerns, certainly.
[19:58:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss f6458f7 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2_eth: add a read deadline field to llio * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f6458f7
[19:58:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 3045d2f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: use read deadline for queued reads * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3045d2f
[20:35:37] <cradek> latency-histogram is sure cool
[20:47:54] <skunkworks> did you see
https://www.youtube.com/watch?v=YwJLJxoKuM8
[20:48:18] <cradek> ooh, neato
[20:56:58] <seb_kuzminsky> skunkworks: did you make the toolpath?
[21:31:50] <skunksleep> No. Something Dewey came up with
[22:02:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 045f4f7 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2_eth: record information so hm2_eth can compute deadlines * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=045f4f7
[22:02:28] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss db06cda 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: use read deadline for queued reads * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=db06cda
[22:02:28] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 21d31e5 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hostmot2: introduce "needs_soft_reset" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=21d31e5
[22:02:31] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 6bb3a52 06linuxcnc 10docs/man/man9/hm2_eth.9 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: detect lost reads and writes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6bb3a52
[22:03:44] <jepler> .. With the default settings, I frequently reach the error cutoff when I introduce 1% packet loss, but that goes way beyond anything I think we would want to call OK
[22:04:00] <jepler> I have only done some simple halrun sessions at .5kHz and 1kHz with this, I haven't run full linuxcnc to see how it behaves
[22:04:31] <jepler> but lost reads and writes are detected (with a force-write after that happens)
[22:04:39] <jepler> and everything that could be tunable is, I think
[22:05:05] <jepler> next step: try it with a pid-stepper configuration and see what happens
[22:05:08] <jepler> afk for the night
[23:44:56] <dgarr> skunkworks: credit to Rudy:
https://www.youtube.com/watch?v=Oh9eCupbsso http://buildbot.linuxcnc.org/doc/scratch/v2.8.0~pre1-ja~dgarr-trt-doc-test~c1ce971/html/motion/5-axis-kinematics.html
