Back
[00:56:16] <linuxcnc-build> build #116 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/116 blamelist: dummy, John Morris <john@zultron.com>
[00:56:17] <linuxcnc-build> build #145 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/145 blamelist: dummy, John Morris <john@zultron.com>
[00:57:18] <linuxcnc-build> build #116 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/116 blamelist: dummy, John Morris <john@zultron.com>
[08:35:01] <cradek> haha, source code forensics labs
[08:38:44] <jepler> I must be missing context
[08:39:49] <cradek> zultron's g52 email
[09:24:48] <mozmck> seb_kuzminsky: possible link for ebo?
http://www.sbf5.com/~cduan/technical/git/
[09:25:00] <jepler> ah
[09:35:02] <cradek> jepler: you're reviving zenbot?
[09:36:31] <jepler> cradek: yeah, slowly working on it
[09:45:20] <jepler> I'm trying to decide whether to order a new 7i90 since I know at least some outputs of the one I have are fried; or cross my fingers that the only damaged I/Os are on the one output connector
[09:45:54] <cradek> do you have one of those LED boards that would let you easily test all the signals on the good connector?
[09:46:03] <cradek> (if not I think I might have one)
[09:46:04] <jepler> yeah, that's a good idea and I do
[09:57:03] <cradek> I'm looking forward to a weekend playing in the shop
[10:38:52] <seb_kuzminsky> cradek: that sounds nice :-)
[10:51:23] <seb_kuzminsky> mozmck: that link is pretty good. I also like this one somewhat:
http://schacon.github.io/gitbook/1_the_git_object_model.html (skip the first part about SHA)
[10:51:53] <seb_kuzminsky> i haven't found any docs that describe this the way i think it should be described
[10:52:33] <seb_kuzminsky> i've got a presentation that i give to new git users at $DAYJOB, but it's not in the kind format or the level of polish where it would be useful without me talking for 30-60 minutes about the slides :-/
[10:53:09] <mozmck> is that book the same as the one here?
http://git-scm.com/book/en/v2
[10:53:33] <seb_kuzminsky> i think they're different
[10:54:00] <mozmck> ok, I just saw the name schacon
[10:54:04] <seb_kuzminsky> i like the Pro Git book you linked, but like so many git docs it's a long slog, not a 15-30 minute "zero to git" start
[10:54:07] <seb_kuzminsky> hmm
[10:54:40] <mozmck> maintained by the same author anyhow
[10:55:07] <seb_kuzminsky> yeah, you're right
[10:55:13] <seb_kuzminsky> the content looks pretty different though
[10:55:38] <mozmck> Yeah, the one you posted is a community book
[10:56:05] <seb_kuzminsky> http://www.gitguys.com/topics/all-git-object-types-blob-tree-commit-and-tag/
[10:58:40] <mozmck> ah, yes - I've seen that site too.
[10:59:22] <mozmck> git can certainly be confusing!
[11:00:14] <seb_kuzminsky> http://eagain.net/articles/git-for-computer-scientists/
[11:00:50] <seb_kuzminsky> i *think* after internalizing the data structures involved it becomes simple and clear
[11:00:55] <mozmck> makes my head hurt
[11:01:13] <seb_kuzminsky> :-(
[11:01:20] <mozmck> :) for computer programmers that's probably so
[11:01:45] <seb_kuzminsky> it's definitely a tool "by hackers for hackers"
[11:02:37] <mozmck> I'm sorta kidding - I think I have a fair handle on it now, but something like that last link would not help a lot of casual git users much I bet.
[11:03:17] <seb_kuzminsky> you're probably right
[11:04:07] <seb_kuzminsky> unfortunately i think that level of knowledge of the git model is pretty important for effectively using git, and for not getting confused about what the different git commands do
[11:04:23] <mozmck> A good gui is really helpful. Not having to remember all the commands is essential if you don't use it every day.
[11:05:24] <seb_kuzminsky> hm, yeah, good point
[11:05:55] <seb_kuzminsky> the gitk and 'git gui' guis are fantasticaly useful, even for a cli fossil like myself
[11:06:25] <mozmck> I have rabbitvcs set up in the "nemo" file manager for my boss.
[11:06:40] <seb_kuzminsky> i sometimes find myself doing git stuff across links where X forwarding is slow and/or awkward, and then i use the text-mode gui called "tig"
[11:07:07] <mozmck> It adds stuff in the right click menu, and is really fairly good for most operations.
[11:07:42] <seb_kuzminsky> it does the "graph of histories" thing that gitk does, and it does the "interactive fine-grained manipulation of the index" that git gui does, all with ncurses
[11:07:58] <mozmck> interesting!
[11:08:22] <mozmck> I mostly use gitg for viewing history and commit logs etc.
[11:08:52] <cradek> magit (in emacs) is really great too, but I've forgotten how to use it
[11:09:03] <cradek> for a while I used it for any nontrivial merge/rebase
[11:09:29] <cradek> I bet it's a lot like tig
[11:09:39] <seb_kuzminsky> how to learn git: step 1: learn emacs
[11:09:46] <mozmck> ouch!
[11:09:56] <cradek> silly, everyone knows emacs already
[11:09:59] <seb_kuzminsky> haha
[11:10:09] * seb_kuzminsky <-- except this guy
[11:10:19] <cradek> unpossible
[11:10:23] * mozmck <-- and this one.
[11:10:28] <seb_kuzminsky> inconceivable!!
[11:10:44] <seb_kuzminsky> i've got a pile of vim customizations instead :-/
[11:11:23] <seb_kuzminsky> vim with cscope integration makes me feel like i've caught up to like 1992 in terms of IDE technology
[11:11:37] <mozmck> :-D
[11:11:53] <cradek> it's funny, I can't imagine writing/manipulating emails in anything other than vim, or doing nontrivial coding in anything other than emacs
[11:12:28] <cradek> I've got you beat I bet - I'm up to at least 1996 technology
[11:13:14] <seb_kuzminsky> you must have twice my brain capacity, i can barely keep one editor in there
[11:16:36] <mozmck> It there a way to update the position of an axis that is moved externally that has an encoder on it? Say I disable the driver, and crank the handle to move it. I want it to track and show position in linuxcnc, and then when I enable the driver again have that be the new position.
[11:17:28] <seb_kuzminsky> mozmck: isn't that already the behavior when the machine is in the "Machine Off" state?
[11:17:29] <cradek> that happens automatically
[11:17:35] <cradek> totally is
[11:17:57] <cradek> also in estop state
[11:18:02] <seb_kuzminsky> err, in any state other than On (Estop, Estop-Reset, and Off)
[11:18:18] <mozmck> hmm, so can I do that for just one axis, while the machine is still on?
[11:18:26] <seb_kuzminsky> i dont think so
[11:19:33] <cradek> nope, the whole architecture is wrong for that
[11:19:54] <mozmck> That's really what I need. The Z is moved by our THC while cutting, and linuxcnc doesn't know about it. So I need to update linuxcnc with the new position when finished with a cut.
[11:20:55] <seb_kuzminsky> do you currently use a thc component between motion and the joint to offset the commanded Z? like dgarr's moveoff?
[11:21:02] <cradek> seems like you'll have to either go to machine off state, or move Z back to where it's expected
[11:21:08] <seb_kuzminsky> brb coffee
[11:21:36] <mozmck> seb_kuzminsky: Our hardware moves the Z independently.
[11:22:48] <mozmck> cradek: what I'm doing now, is sending the new position on a hal pin from my component, and using a subroutine which does a G92 with that position after finishing a cut.
[11:22:53] <ssi> mozmck: I ran into those sorts of issues with my thc
[11:22:59] <ssi> I forget how I handled it
[11:24:07] <cradek> I don't understand how that would solve the problem, so I must not understand the problem
[11:24:34] <cradek> that doesn't change the hal-level commanded position to match the (new) feedback position
[11:24:44] <mozmck> only problem is if a cut has a problem and you stop it in the middle, that sub doesn't get run. I think I can do what I need with some fancy hal stuff.
[11:25:18] <mozmck> Ah, there isn't actually an encoder, but I could make my component act like there was.
[11:25:50] <ssi> I believe on mine, the thc component intercepts the stepgen and makes "unaccounted" changes to the axis
[11:25:53] <cradek> it sounds like what you want is an orderly removal/zeroing of your external offset and simultaneous update of the command to match the new feedback
[11:26:45] <cradek> can the thc just cause motion upward all the way when it stops operating, and have that be the zero external offset?
[11:27:21] <mozmck> not very well. zero is the material top
[11:27:26] <cradek> the external offset thing is sure an unsavory hack, isn't it
[11:28:01] <seb_kuzminsky> yep
[11:28:02] <mozmck> thanks ssi, I'll ponder that.
[11:28:20] <seb_kuzminsky> ssi: sounds like the same technique moveoff uses
[11:28:22] <cradek> sure, zero in the gui is the material top, but upward a safe amount could be zero external offset
[11:28:45] <cradek> they don't have to be the same do they?
[11:29:19] <ssi> mozmck: I was trying to say that maybe there's a better way
[11:29:23] <ssi> but my internet decided to drop out for a minute
[11:29:47] <ssi> might be better if we had an actual pid in linuxcnc that was moving the axis to hold torch voltage
[11:29:50] <ssi> so there's no "unaccounted" changes
[11:29:52] <mozmck> cradek: I'm not sure I follow you. zero external offset means I have not moved since taking control of Z
[11:29:56] <ssi> I don't know if that's even possible
[11:30:26] <cradek> mozmck: it's not you, it's me being half-baked
[11:30:35] <cradek> ... well I mean my ideas are
[11:30:44] <cradek> I'm not
[11:30:44] <mozmck> ssi: I don't know - our hardware moves the Z independently of linuxcnc while cutting, then turns it back over to linuxcnc when done.
[11:31:09] <cradek> and you can't just move back to zero because that's downward/unsafe?
[11:32:11] <mozmck> Yes, basically we don't know where the material is at that point.
[11:32:37] <seb_kuzminsky> mozmck: i dont understand your architecture
[11:32:52] <mozmck> we might be cutting corrugated tin and we started in the valley and ended on top a ridge.
[11:33:01] <ssi> the metal will move A LOT during the cut
[11:33:08] <mozmck> ssi: that too
[11:34:05] <mozmck> seb_kuzminsky: ok, basically Z steps from linuxcnc are fed into our thc. If the torch is not on, the thc just passes them through to the drive.
[11:34:09] <cradek> if you open up ferror and hook up feedback, the DRO *will* update if it's set to show feedback position
[11:34:53] <cradek> but then if you have this big offset and you issue MDI G0 Z it may very well do a non-obvious thing
[11:34:55] <mozmck> If the torch is on, the thc takes over and controls the Z directly. I do the accel/deccel and everything in the hardware.
[11:35:06] <seb_kuzminsky> mozmck: that seems like a surprising place to do thc
[11:35:18] <ssi> seb_kuzminsky: it's surprisingly common :/
[11:35:31] <cradek> say command is 0, external offset is +2, DRO shows +2, you issue MDI G0Z1, it will move up to DRO=+3
[11:35:31] <ssi> JT-Shop: are you alive in here?
[11:35:35] <mozmck> seb_kuzminsky: in hardware?
[11:35:35] <ssi> jt wrote the thc comp which I'm using
[11:35:41] <seb_kuzminsky> i clearly need to build a plasma table to learn more about this stuff
[11:35:56] <cradek> seb_kuzminsky: surely you mean have mozmck send you a free one
[11:36:02] <ssi> but that's what I'm saying, it'd be nice if linuxcnc had a more "active" role in the thc
[11:36:08] <ssi> so it was aware of the motion monkeying
[11:36:18] <seb_kuzminsky> mozmck: so you're not using a hal component at all, to do your thc? it's all handled in hardware after the fpga clocks out the steps?
[11:36:23] <JT-Shop> hanging siding
[11:37:02] <pcw_home> I guess motion could have a upstream of FE checking and acceleration limited offset input
[11:37:34] <mozmck> seb_kuzminsky: that's partly correct - but the THC is between linuxcnc and the fpga. During a cut linuxcnc does not move the Z at all.
[11:37:42] <pcw_home> not easy if allows during motion
[11:38:08] <pcw_home> (because it needs to be fed into the planner/lookahead)
[11:38:39] <seb_kuzminsky> having thought about this for all of 30 seconds, i think i would want an XY machine with the vertical axis handled separately in HAL. the vertical would be in either "THC" mode or "against the top hard stop" mode. in thc mode, a pid drives it up/down based on torch voltage feedback, once you turn the torch off it moves up to the top just to get out of the way
[11:38:54] <mozmck> :)
[11:40:16] <pcw_home> If motion had an upstream mux from ext (accel limited) and planner it might be a bit cleaner than doing it all in hal
[11:40:52] <ssi> seb_kuzminsky: there has to be a little more motion than that, there's some stuff that happens before there's an arc
[11:41:15] <mozmck> seb_kuzminsky: At some point our THC should be able to do that - full stand alone. It needs to handle touch-off, move to pierce height, down to cut height etc.
[11:41:20] <seb_kuzminsky> ssi: you power up the torch and seek down until you establish an arc?
[11:41:22] <pcw_home> and corner locking etc
[11:41:35] <ssi> seb_kuzminsky: jog down until you encounter the material with a switch or ohmic sensing
[11:41:39] <ssi> then jog up to pierce height
[11:42:10] <ssi> fire the torch, wait a pierce delay, feed downward to initial cutting height, start motion, then adjust the torch height with thc
[11:42:19] <ssi> can't do thc until you have a stable arc
[11:42:32] <seb_kuzminsky> that all sounds doable with a little bit of C
[11:42:39] <seb_kuzminsky> pcw_home: what's corner locking?
[11:42:44] <ssi> and there's other little bits of nastiness like what happens when the voltage goes out of range due to corner accel, etc
[11:42:52] <ssi> er, that's corner locking :)
[11:42:54] <seb_kuzminsky> heh
[11:43:10] <seb_kuzminsky> what happens to the torch voltage when you corner?
[11:43:11] <ssi> if you have to do a hard corner, there's a decel/accel at the corner, and the torch will dive if the thc allows it to
[11:43:18] <mozmck> seb_kuzminsky: it goes up
[11:43:27] <mozmck> so tip goes down
[11:43:55] <seb_kuzminsky> hmm
[13:28:41] <dgarr> is this file licensed appropriately for inclusion in LinuxCNC?
https://github.com/FernV/linuxcnc-features/blob/master/support/cxf/engrave-feature
[13:29:53] <cradek> no; linuxcnc is conveyed under GPL2 so added files need to be compatible with that
[13:30:52] <cradek> "version 2 or (at your option) any later version" is by far the best choice today for new linuxcnc parts
[13:31:35] <jepler> >>>
[13:31:35] <jepler> 40 In addition, by making a contribution to this project, I certify that:
[13:31:39] <jepler> 41
[13:31:41] <jepler> 42 (e) The contribution is covered under a license that is compatible
[13:31:44] <jepler> 43 with the GNU GPL version 2 with the "or later" clause.
[13:31:46] <jepler> <<<
[13:32:14] <cradek> interesting; guess we decided not to allow "2 only" anymore
[13:32:15] <jepler> we require this in all new submissions to LinuxCNC
[13:32:25] <dgarr> ok, that's what i thought, thank you, nick, fernv would have to do something if they want it in features_preview
[13:32:39] <dgarr> thanks
[13:33:18] <jepler> ah a better link than the one I was going to give you is
http://linuxcnc.org/docs/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy
[13:33:28] <jepler> > To improve tracking of who did what, we use the "sign-off" procedure introduced by the Linux kernel. The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. The rules are pretty simple: if you can certify the Developer’s Certificate of Origin 1.1 with GPLv2+ clause, then you ju
[13:33:30] <cradek> often people are happy to change the statement so the older version is acceptable too
[13:33:34] <jepler> st add a line saying
[13:33:37] <jepler> Signed-off-by: Random J Developer <random@developer.example.org>
[13:33:50] <seb_kuzminsky> i bet nick and fern wont mind changing their license
[13:34:18] <dgarr> i will skip it for now
[13:34:52] <cradek> thanks very much for paying attention to that
[13:43:59] <skunkworks> zlog
[15:49:03] <jepler> Tom_itx: thank you for running our logger btw
[16:27:51] <|cncbasher|> hi all sorry to say but back up on irc
[16:29:18] <JT-Shop> hey Dave
[16:30:19] <|cncbasher|> hi
[16:31:39] <|cncbasher|> did you get the xml file ok ?, from my other email add
[16:32:05] <|cncbasher|> oh change your contact email for me to the new one too
[16:32:15] <JT-Shop> I got the first one ok after a couple of hours lol
[16:32:25] <JT-Shop> but you can convert them in LinuxCNC now
[16:32:36] <|cncbasher|> yea , you need longerwires it seems
[16:32:47] <|cncbasher|> arh ok , not tried that
[16:33:05] <JT-Shop> yea, just run the Stepconf Wizard
[16:33:27] <JT-Shop> thanks to cmorley for porting my program to the wizard
[16:33:32] <|cncbasher|> ok , just trying to help a person with a 7i90
[16:34:20] <|cncbasher|> problem is we are not sure the card is loaded with a bit file, so i'm on sorting that out
[16:35:47] <JT-Shop> yea, I know nothing about the 7i90 so I'm no help
[16:36:31] <Tom_itx> i've got a 7i90?
[16:36:38] <|cncbasher|> hi tom
[16:36:46] <Tom_itx> you can check it with mesaflash iirc
[16:37:02] <|cncbasher|> have you a hal config setup etc
[16:37:19] <Tom_itx> for 7i90? yeah
[16:37:29] <Tom_itx> you just use the CONFIG= line
[16:37:33] <Tom_itx> no bitfile line
[16:37:45] <Tom_itx> load the bitfile with mesaflash
[16:37:55] <|cncbasher|> whats the installed bit file by default
[16:38:04] <Tom_itx> i'm not sure
[16:38:12] <Tom_itx> i use a custom one i did
[16:38:55] <|cncbasher|> ok , it's only the gentlemen knows nothing of the 7i90 or how to set it up
[16:39:10] <|cncbasher|> so i'm doing it by remote haha
[16:39:26] <Tom_itx> is it messed up?
[16:39:52] <|cncbasher|> i read the contents , but makes no sense or match to a bit file
[16:39:54] <Tom_itx> i messed mine up once and wrote how i recovered it here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Recover_Corrupt/Blank_EEPROM_5i24%2C6i24%2C7i24%2C_6i25
[16:40:06] <|cncbasher|> or at least to the pin and xml
[16:40:07] <Tom_itx> it has a backup bitfile as well iirc
[16:41:12] <Tom_itx> you can interrogate it with mesaflash to see what it has loaded
[16:41:19] <Tom_itx> one sec..
[16:43:12] <|cncbasher|> ok thanks , ui use readhmid and i got a pin lint
[16:43:14] <|cncbasher|> list
[16:43:44] <atom1> you need the latest mesaflash to do what that link suggests though
[16:43:55] <|cncbasher|> but a message over that the card has to be programmed or it wont make sense
[16:44:09] <|cncbasher|> yea i have the latest
[16:44:25] <atom1> doesn't sound like you need that though
[16:44:45] <|cncbasher|> would be nice if the bit file name was listed thats loaded
[16:45:04] <atom1> yeah
[16:45:29] <|cncbasher|> save me trying to guess from the other side of europe
[16:45:53] <atom1> is it a stepper or servo bit file?
[16:45:59] <|cncbasher|> servo
[16:46:09] <atom1> iirc stepper is default
[16:46:45] <seb_kuzminsky> pcw_home: is it safe to connect an fpga input pin directly to a switch to ground, or do i need a 7i37 (or similar) to massage the signal somehow?
[16:46:52] <|cncbasher|> seems to be 8 encoders and 12 pwm with 6 steppers on p3
[16:47:32] <atom1> seb_kuzminsky, i do that on my limits
[16:47:50] <atom1> make sure it's input :)
[16:48:02] <|cncbasher|> seb i'd stick a series resistor in ,
[16:48:17] <atom1> if you wanna play it safe, yeah
[16:48:46] <|cncbasher|> but going to ground you should be ok , so long as theirs no ground loops
[16:49:23] <seb_kuzminsky> there's a 10k pull-up on inputs in the fpga iirc
[16:49:29] <atom1> keep in mind the logic is backward coming straight from the port
[16:49:36] <seb_kuzminsky> yep
[16:49:57] <seb_kuzminsky> alright, cool, thanks guys
[16:53:17] <atom1> |cncbasher|, remember to --reload or power cycle after loading a file
[16:53:37] <|cncbasher|> yea
[16:54:37] <|cncbasher|> looks like it has 8 encoders 4 on each p1 & p2
[16:54:52] <|cncbasher|> with 6 servo pairs
[16:55:08] <|cncbasher|> and 5 stepgens on p3
[16:55:37] <PCW> 7I90s are always pre-loaded with 2 bitfiles (P and S) both are EPP interfaced so
[16:55:38] <PCW> mesaflash can be use to re-write them to whats required
[16:55:55] <|cncbasher|> is their anyway knowing if it's on a parallell port , from what you read out ?
[16:56:14] <|cncbasher|> i presume the fact that i have read it , means it must be
[16:56:46] <PCW> It will only work on a a parallel port unless you change the firmware
[16:57:13] <|cncbasher|> arh thanks , that helps a lot
[16:58:01] <PCW> you can just ground inputs for switches etc. but make sure the switch ground is direct from the 7I90
[16:58:17] <atom1> i see there are epp, serial and spi bitfiles in the 7i90 dir
[16:59:04] <PCW> yes but only EPP works with mesaflash currently
[17:00:05] <PCW> (if you want to try one of the other config types make sure you always have a EPP config to fall back on)
[17:00:12] <atom1> what method is used to load the others?
[17:00:30] <PCW> Mesaflash over EPP
[17:00:33] <seb_kuzminsky> pcw_home: jepler added support for flashing 7i90 over spi
[17:00:46] <atom1> i thought he may have
[17:00:58] <PCW> Ahh but of course SPI will be quite host specific
[17:00:58] <|cncbasher|> yea thats the version i use
[17:01:02] <seb_kuzminsky> it's in 3.1 and 3.2
[17:02:17] <PCW> there's one more firmware type which is ssremote
[17:20:43] <jepler> yes, 7i90 can be flashed over linux /dev/spidev* (I tried that just last week) but very few linux systems have a SPI interface exposed
[17:22:58] <|cncbasher|> I'm going to try spi shortly on a arm mcu , so could be interesting
[17:23:44] <jepler> I have successfully used a 7i90 in spi mode on the (now discontinued) odroid u3, but it required kernel patches beyond preempt-rt.
https://github.com/jepler/u3-7i90
[17:25:08] <|cncbasher|> thanks
[17:25:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05zultron/glo-2.6-remap-startline-fix 6ae4a34 06linuxcnc 10(10 files in 2 dirs) tests: add a motion-logger test of a possible remap bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ae4a34
[17:25:39] <KGB-linuxcnc> 03John Morris 05zultron/glo-2.6-remap-startline-fix 9df8235 06linuxcnc 10src/emc/task/emctaskmain.cc Bugfix: Start line and remap interaction * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9df8235
[17:26:05] <jepler> in the kernel tree you'll find that some of the commits were to spi and spidev in general, and one commit was for the particular spi chipset in the u3.
https://github.com/jepler/odroid-linux/commits/odroid-3.8.13-rt
[17:26:27] <jepler> and as it's based on 3.8 it's all rather stale and unlikely to apply to current kernels as is
[17:26:41] <jepler> .. but on droid I lucked out and spi was the only thing where I needed to fix latency in the kernel
[17:26:41] <|cncbasher|> did u find 3.8.13-rt ok ?
[17:27:50] <jepler> it would run for days with good latency, no higher praise than that
[17:28:14] <jepler> though since reviving the system after a year in storage it did freeze overnight while running linuxcnc and I don't know why..
[17:30:25] <|cncbasher|> ok thanks for the heads up
[17:30:38] <|cncbasher|> if i find anything i'll let you know
[17:31:59] <|cncbasher|> ive done a small ethernet 5 axis stepper controller , which should be done in a few weeks , just waiting for some boards
[17:37:31] <seb_kuzminsky> jepler: the buildbot's u3 has been up for 381 days now, i'm amazed it's as good as it is
[17:48:23] <jepler> wow
[19:06:06] <cradek> > Turned out to be the motor encoder missing feedback.
[19:06:13] <cradek> [Y jog not stopping]
[19:06:52] <cradek> hey that actually fits with "every time I poke the jog arrow it goes a little faster"
[19:07:05] <cradek> they must have grossly wrong ferror limits though
[19:17:25] <andypugh> Like, none
[19:18:17] <cradek> well say it's an inch, and you poke and release jog, and linuxcnc thinks it's moved half an inch
[19:18:25] <cradek> it will run away forever at some speed
[19:19:14] <cradek> probably some increasing-until-pid-saturates speed
[19:19:37] <cradek> on my real machines, pid saturation causes a fault
[19:22:29] <andypugh> Why would it think that it has moved at all?
[19:22:51] <andypugh> Or was the encoder working a bit, just not properly?
[19:31:55] <cradek> it wouldn't
[19:32:39] <cradek> the command moves a half inch, the feedback doesn't move at all, integrator winds up, ferror doesn't trip because |command-feedback| < 1inch
[20:24:39] <PCW> yeah failed encoders are bad
[20:27:31] <andypugh> I should know this, it is _exactly_ the problem I am chasing at work. Though in that case it is the position of the thermostat
[20:28:06] <andypugh> (luckily that problem careers towards cold engine, not melted engine)
[20:37:32] <PCW> I think it would be good to have an encoder sanity check for indexed encoders,
[20:37:33] <PCW> that would probably have caught this right away
[20:38:56] <PCW> (dont know if Jon E's hardware can do latch on index or just clear on index)
[20:39:08] <andypugh> That sounds like an idea worth elaborating on on the dev mailing list…
[20:40:14] <PCW> yeah could be added to the software encoder as a first model
[20:41:33] <cradek> the reporting of this was so bad
[20:41:44] <cradek> sometimes it happened on different axes, or all of them
[20:42:03] <cradek> and it wasn't reported that homing also ran away (surely they tried to home), only jogging
[20:42:36] <cradek> it led to lots of really terrible advice (no fault of the answerers)
[20:43:17] <PCW> a reasonable FE limit should catch this also
[20:43:53] <PCW> Yeah I had not thought that it might be a runaway
[20:44:53] <PCW> For a sanity check, my theory is you always latch the count at index and check that successive latched counts always differ by counts/turn (or 0)
[20:48:53] <andypugh> If they lost AB then they probably lost Z. Not that your idea isn’t excellent, as it would also trap missed counts.
[20:51:51] <PCW> for velocity mode servos a little fuzzy logic would help as well
[20:51:53] <PCW> (The PID loop is commanding a velocity V, If the encoder velocity is not close to V for X mS = trouble)
[20:53:36] <PCW> ( Another reason to scale the PID loop in machine units )
[20:55:24] <andypugh> add v-error to f-error…
[20:57:01] <PCW> the PID comp has all it needs to do this check (FB deriv and its own output)