Back
[07:15:41] <jepler> mozmck: nml was designed to support remote user interfaces. nobody, or at least very few people, use this capability.
[07:16:24] <jepler> mozmck: mah wants to change things, and he has claimed that some of his new directions are to enable things like this
[07:17:00] <jepler> mozmck: he seems to be good at marketing ideas like that
[07:18:21] <jepler> as far as I'm concerned, mah's never clearly articulated the relationship behind his ideas like "replace nml with 0mq" and "support remote user interfaces"
[07:19:05] <jepler> if your real goal is to support remote user interfaces, I'd say to do it with nml and fix some bugs along the way
[07:19:13] <jepler> .. and then make sure it doesn't bitrot again, by actually using it
[07:19:55] <jepler> but now that machinekit is a distinct project from linuxcnc, they can approach it like they want to approach it and if they attract enough developers and users to be a viable project, that's great.
[07:22:38] <jepler> and we can continue to say, "well, the bullet-list of nml features says that remote UIs work, but we've spent the last ten years too tired to even test it"
[07:57:30] <archivist> I thought a number were using it remotely
[07:59:20] <mozmck> Looks like he wants to have a remote HAL interface that can show status of bits, etc
[07:59:46] <mozmck> and he thinks NML is too inflexible to extend.
[08:01:22] <archivist> is that because it is not some OOP over loadable thing
[08:01:45] <mozmck> I don't know for sure - NML is written in C++
[08:02:13] <mozmck> he thinks it doesn't have enough language bindings
[08:08:50] <skunkworks> Also he doesn't want the realtime running on the same machine as the ui..
[08:09:26] <mozmck> Yes, but isn't that part of any remote UI?
[08:09:44] <archivist> except 99% of the users do want just that
[08:10:26] <mozmck> I can understand wanting a separate UI say on a different computer.
[08:10:42] <skunkworks> well - maybe not 99% - a lot of people run things like smoothstepper and such...
[08:10:51] <skunkworks> (externan motion)
[08:11:01] <archivist> well that are mach users :)
[08:11:03] <skunkworks> (external motion control)
[08:11:07] <archivist> they
[08:11:09] <skunkworks> :)
[08:11:17] <archivist> and have to
[08:11:52] <archivist> I think code speed matters more so they can co exist
[08:12:22] <mozmck> A remote UI would allow a control box to be used such as a beaglebone that cannot handle the graphics well, and the UI could be on any computer in theory - Linux, Win, Mac.
[08:12:43] <skunkworks> mozmck, exactly what MAH is trying to do.
[08:13:24] <mozmck> But the amount of changes MAH is making seem excessive.
[08:13:54] <mozmck> But I also don't know the guts of linuxcnc and NML well enough - hence my question.
[08:13:54] <skunkworks> time will tell
[08:14:03] <CaptHindsight> but how many machine tools would be operated remotely? Are shops looking to automate so that they can control their VMC while sitting on the beach from their smartphone?
[08:14:26] <mozmck> I think that is more remote than this idea.
[08:14:51] <CaptHindsight> the whole remote thing is for toy machines and glue guns
[08:14:53] <mozmck> It is more like the CNC Shark router if you have seen that (Rockler sells them)
[08:16:02] <mozmck> From what I have understood though, that kind of thing is possible now in linuxcnc.
[08:16:37] <skunkworks> as of right now (as I understand it) some gui has to still run on the realtime device..
[08:17:27] <mozmck> hmm, ok
[08:17:33] <skunkworks> (but I have never needed to play with that...)
[08:17:52] <skunkworks> I like my atom or whatever board that runs everything.
[08:17:59] <CaptHindsight> imx6, A10/A20, Exynos all have GPU's and enough cores, speed and DDR3 bandwidth to support motion and a GUI, for some reason they got hooked on the weak AM355x that needs a 2nd PC for the UI
[08:18:36] <archivist> http://www.wallacecompany.com/machine_shop/EMC2/remote_notes.html
[08:18:37] <mozmck> probably because they are available in a board with a PRU for cheap
[08:19:49] <CaptHindsight> imx6, A10/A20, Exynos + FPGA
[08:20:09] <mozmck> but does such a board exist yet?
[08:20:26] <CaptHindsight> I though there must be some TI influence
[08:21:11] <CaptHindsight> yes, there are FPGA boards for the above, plus the BBB still needs and IO board
[08:21:19] <CaptHindsight> and/an
[08:22:28] <archivist> and there was this thread
http://www.mailinglistarchive.com/html/emc-users@lists.sourceforge.net/2010-03/msg00770.html
[08:22:37] <mozmck> true about the IO board. didn't know there were FPGA boards available - where can I buy one?
[08:23:25] <mozmck> I saw someone on the mailing list talking about making a board with an ARM + FPGA
[08:23:31] <CaptHindsight> there is also lots of influence from that maker/reprap market for duino and Rpi type boards
[08:24:42] <mozmck> archivist: interesting. I think one of the things MAH is wanting to to export HAL pins over the network.
[08:25:04] <mozmck> to to = to do is
[08:27:27] <archivist> I think messages could be able to send more/use less bandwidth by sending diffs too
[08:29:02] <archivist> like you never need to send the entire tooltable just send the next tool table entry needed
[08:32:12] <mozmck> oh, MAH also wants to replace INI files with a configuration "service" not sure why other than INI files are "old".
[08:34:21] <cradek> mozmck: the "old" thing is a common theme, isn't it
[08:34:46] <archivist> I hate chasing new bling
[08:35:07] <mozmck> seems to be, and is a complete non-argument
[08:35:30] <cradek> more interesting is for us to think about what we should be doing with our project...
[08:39:55] <skunkworks> I think for me and what I hear... Standard way to slave axis, jog while paused (which includes changing tool offsets), circular arc blinding in all 9 axis. (now that rt_preemt seems to be working well)
[08:40:44] <archivist> slaving axes is likely to push the maths a bit harder
[08:40:53] <archivist> but I want that
[08:41:28] <cradek> yes I would definitely like changing offsets while paused
[08:42:32] <CaptHindsight> xenomai support to be safe, since RTAI is really down to 3 active devs and even preempt_rt is running on the fumes of one main dev
[08:47:35] <skunkworks> lost connectioin..
[08:47:37] <skunkworks> But I really cannot do any of that (other than testing) :)
[08:48:10] <skunkworks> xenomai support would be nice..
[08:48:26] <skunkworks> but hey - we are up to 2 realtime kernels now!
[08:49:09] <CaptHindsight> that UBC branch has it
[08:49:17] <skunkworks> sure
[08:49:30] <skunkworks> I have played with xenomai
[08:53:15] <skunkworks> * jog while paused.. I would think you would also have to be able to back up a move or 2... So I don't know how the heck that would work..
[08:55:56] <CaptHindsight> won't it depend on the reason for the jog while paused? jog from and back to the same locations vs jog to a different coordinate and then continue the program
[08:57:46] <skunkworks> 2 that I know of - cleaning swarf, broken tool. cleaning swarf is almost doable strictly in hal with offset... Broken tool would have to be jogged off, replace - retouched off, start over a few moves back.
[08:58:05] <skunkworks> assuming the broken tool didn't totally destroy the part.
[08:58:35] <skunkworks> (I would just use RFL...)
[08:59:01] <skunkworks> although my programs are not that complicated..
[09:01:22] <skunkworks> I can almost do cleaning of swarf now.. (just cannot move away..) I have pause, then spindle override to 0%. I can then pull shavings out of the way if I need to..
[09:02:14] <mozmck> I did a pause the other day, moved away, came back and did run-from-line and it worked fine.
[09:03:11] <mozmck> I had to make sure to come back to the right place though. Oh, that is with emc2 2.4 I think - on hardy (thinking about "new" cradek)
[09:04:53] <skunkworks> new cradek?
[09:04:59] <skunkworks> I like the old one..
[09:05:39] <mozmck> heh, I guess it was "old" we were talking about - everything "old" is bad by definition you know...
[09:09:53] <CaptHindsight> http://linuxgizmos.com/ti-spins-cortex-a9-sitara-soc/ this TI ARM SOC might be nice, but TI always tends to not offer the actually useful parts to other than handful of manufacturers
[09:11:19] <cradek> I understand that with jepler's work, adding support for another new rtos is easier now. if someone wanted to work on xenomai that would be terrific.
[09:12:10] <jepler> Yes, I tried to structure uspace so that it can be adapted to other userspace realtime models
[09:12:16] <CaptHindsight> I'm concerned that it might end up being the only option in the next year
[09:12:27] <jepler> since there's only one (plus the now-deleted "pth" implementation), it's hard to say if it really meets the needs
[09:13:06] <jepler> but basically the concept is that you write a subclass of class RtapiApp; and in the right place, you create an instance of your subclass instead of an instance of Posix, based on e.g., testing if the kernel supports xenomai
[09:15:09] <jepler> one thing I notice is that rtapi_delay might need to depend on the RTOS in rtapi_app, so that would need to be moved out of uspace_common.h
[09:25:58] <mozmck> So would it be best to start with uspace for xenomai? I thought xenomai was more like RTAI (so far)
[09:26:37] <cradek> I don't think xenomai uses kernel modules, so I bet it is much more like uspace
[09:27:16] <mozmck> also, from what I read xenomai 3 will be based on preempt-rt? Or did I read incorrectly?
[09:28:14] <jepler> xenomai's kernel mode realtime model did not appear to support FP
[09:28:20] <mozmck> xenomai 2 is a dual kernel setup:
http://www.xenomai.org/index.php/Xenomai:Roadmap#Toward_Xenomai_3
[09:28:34] <jepler> .. mah copied in somebody else's math library into ubc3
[09:28:36] <jepler> I'd rather avoid that.
[09:28:42] <mozmck> I see.
[09:29:49] <mozmck> but if xenomai 3 is based on preempt-rt, then what advantage would xenomai give? especially if the worry is over the availability of preempt-rt?
[09:29:59] <jepler> but .. I don't know anything about xenomai. I don't think I've ever booted a xenomai kernel
[09:33:51] <CaptHindsight> well how will this work? If the preempt_rt project is driven by only one dev and he only works on this in his spare time since there are no funds left for him.
[09:34:04] <pcw_home> looks like xenomai 3 is going to depend on preemt-rt
[09:34:20] <cradek> maybe it will get more eyes then, which is good
[09:34:31] <CaptHindsight> will xenomai absorb the preempt_rt development?
[09:34:45] <cradek> none of us know this
[10:07:14] <cradek> it's amazing how gene can derail any thread
[10:09:54] <skunkworks> heh
[10:10:31] <skunkworks> btw - how come the new tp isn
[10:10:31] <pcw_home> might be a good thing sometimes
[10:10:36] <cradek> yeah
[10:10:36] <skunkworks> isn't in 2.6?
[10:10:42] <cradek> skunkworks: oh you
[10:10:48] <skunkworks> :)
[10:11:31] <mozmck> I think we should back-port it to 2.3 so I don't have to upgrade my router table.
[10:12:43] <cradek> mozmck: that's a terrible impression of him. need much more whining.
[10:14:38] <mozmck> I'm going to switch back to Mach1 if it's not done tomorrow!
[10:49:12] <pcw_home> https://www.youtube.com/watch?v=WD8txWpcoQM
[10:53:11] <mozmck> fascinating!
[10:55:05] <jepler> super neat indeed
[10:57:21] <cradek> what'd I miss?
[10:58:42] <mozmck> pcw_home's youtube link
[11:25:00] <memfrob> does anyone know the difference between the rebase branches and the non-rebase preempt-rt branches?
https://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git
[11:26:15] <memfrob> rebase branches looks a lot easier to dig through preempt specific changes, non rebase looks more upstream, not sure though.
[11:26:40] <jepler> I'll let you know what I can discern if the repository eventually gets around to cloning...
[11:26:46] <jepler> linux's git history is big
[11:27:14] <jepler> remote: Counting objects: 3824796
[11:27:59] <jepler> Receiving objects: 0% (1704/4203701), 468.00 KiB | 288.00 KiB/s
[11:28:15] <memfrob> i think the trees themselves are identical but the way the commits get squashed is different
[11:28:34] <memfrob> (that takes about 2 hours over my incredibly slow DSL connection)
[11:28:53] <memfrob> 15 minutes with comcast and AT&T U-verse
[11:29:12] <jepler> I'm getting anywhere from 60kB/s to 600kB/s here
[11:29:24] <memfrob> thats not a large gap at all! :P
[11:32:31] <jepler> https://groups.google.com/forum/#!msg/linux.kernel/DrSYztiSt5s/upPSKAUijOsJ
[11:32:35] <jepler> this seems to explain the methodology
[11:32:56] <jepler> so a -rebase branch is rebased and a non-rebase branch is not rebased
[11:33:13] <jepler> it sounds like the intent is for them to alawys have the same content
[11:33:35] <jepler> -rebase makes prettier history, non-rebase is better for basing git work on since history won't be yanked out from under you when you build commits on top of them
[11:34:02] <memfrob> ahh ok
[11:34:19] <memfrob> so it is the same tree!
[11:34:40] <jepler> you have the luxury of being able to verify that fact for yourself if you want
[11:34:43] <jepler> e.g., $ git diff v3.0.17-rt33 v3.0.17-rt33-rebase
[11:35:04] <memfrob> oh thats how you diff branches..
[11:35:25] <jepler> yup, that's right
[11:35:43] <jepler> hmmm I seem to have misplaced my forum credentials
[11:35:46] <memfrob> i normally merge branch into tree then diff the merge.
[11:36:02] <memfrob> thats a lot prettier.
[11:36:10] <jepler> jthornton: is that top attachment in the image-to-gcode thread -- the one that's not visible to non-members -- a copy of the script, or is is it something else?
[11:36:24] <jepler> memfrob: if you did that very often, you'll be glad to know about this!
[11:36:42] <memfrob> yeah i did..
[11:36:49] <memfrob> god it was HORRIBLE
[11:37:14] <jepler> :-/
[11:37:50] <memfrob> sorry, a bit jumpy.
[11:42:43] <jepler> Receiving objects: 17% (745836/4203701), 252.43 MiB | 284.00 KiB/s
[11:43:04] <jepler> huh, linuxcnc didn't switch to git until jan 2010
[11:43:25] <jepler> according to tag cvs-import
[11:43:33] <jepler> seems like we've been doing this forever
[11:44:00] <memfrob> you used to use SVN correct?
[11:44:04] <cradek> oh god
[11:44:10] <cradek> no, it was cvs
[11:44:16] <memfrob> even worse!
[11:44:17] <cradek> we were never suckered into svn
[11:44:43] <jthornton> jepler, yes it is the script. I placed a copy here in case you want to gander at it
http://gnipsel.com/files/g-code-generator/
[11:44:45] <skunkworks> jepler,
http://electronicsam.com/images/KandT/testing/image-to-gcodev3.7.zip
[11:44:48] <mozmck> jepler: the top attachment is image-to-gcodev3.7.zip
[11:44:50] <skunkworks> heh
[11:45:11] <memfrob> still better than mercurial. you need special networking options enabled in the kernel in order to use hg email.
[11:45:36] <cradek> I still wish gitweb was as good as cvsweb was
[11:46:19] <memfrob> all those attic and CVS folders, yep.
[11:46:52] <jepler> every time I tell cradek nobody cares about gitweb
[11:46:57] <jepler> the only mistake was writing gitweb in the first place
[11:47:09] <jepler> cvsweb was necessary because all the metadata was on the wrong end of a network link
[11:47:10] <memfrob> i like gitweb.. a lot actually.
[11:47:28] <jepler> and you needed to digest it over there and send the salient bits down the network
[11:48:00] <cradek> jepler: you're not wrong
[11:48:51] <cradek> (but isn't it hard to say that while waiting for the multigigabyte download you need to look at some history?)
[11:50:15] <cradek> jthornton: it would be absolutely great if alex/harmonist wants to improve and maintain i2g
[11:50:43] <jepler> the code's not obviously terrible
[11:51:39] <jepler> the guy is clearly actually using it
[11:52:01] <jepler> I'm happy if someone can help him learn enough git to put his stuff in linuxcnc master branch
[13:06:29] <CaptHindsight> does scarakins use the new trajectory planner? Is the same trajectory planner used for all the different kinematics?
[13:11:44] <seb_kuzminsky> all kins use the same trajectory planner
[13:13:14] <skunkworks_> so in master - it uses the new tp
[13:14:12] <skunkworks_> but remember - it only uses look ahead on xyz moe
[13:14:14] <skunkworks_> move
[13:14:15] <skunkworks_> moves
[13:23:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 3e60a9b 06hostmot2-firmware 10debian/rules deb: use debhelper to fix permissions * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=3e60a9b
[13:24:27] <seb_kuzminsky> cradek: thanks for adding that
[13:30:28] <cradek> ?
[13:30:35] <seb_kuzminsky> kgb for hm2
[13:30:44] <cradek> oh! welcome.
[13:35:29] <CaptHindsight> skunkworks: does XYZ only apply to trivkins?
[13:35:44] <skunkworks> The planning is done before the kins.. IIRC
[13:36:23] <CaptHindsight> ok that makes sense
[13:36:43] <cradek> seb_kuzminsky: not meaning to nag, but have you looked at
http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/proposed
[13:37:46] <seb_kuzminsky> thanks for the reminder. i'll try to look at it today
[13:38:03] <mozmck> I notice my little patch went into 2.6 - does that stuff get into master somehow as well?
[13:38:21] <seb_kuzminsky> mozmck: yes, we merge 2.6 into master fairly often
[13:38:37] <mozmck> Ok, I just wondered.
[13:38:39] <seb_kuzminsky> the intent is that master should get all the good safe changes that the stable branch(es) get
[13:38:48] <mozmck> are there often conflicts?
[13:40:14] <skunkworks_> between programmers? all the freaking time!
[13:40:16] <skunkworks_> ;)
[13:40:24] <mozmck> :)
[13:41:03] <mozmck> I was thinking if master had diverged and a merge is attempted it could get ugly, but that may not happen often.
[13:41:23] <seb_kuzminsky> heh
[13:41:31] <cradek> mozmck: usually it's very easy
[13:41:48] <cradek> mozmck: the worst part is often the docs, but usually even that isn't bad.
[13:45:51] <cradek> when that merge (in the code) is hairy, it's always for a reason -- because something hairy has happened between the branches and you really do have to figure it out and fix it. the "merging upwards" process is really good at helping you maintain your various stable and development branches.
[13:47:08] <mozmck> as in maintain compatibility?
[13:47:13] <cradek> fwiw, "Merging upwards" is documented in man gitworkflows
[13:47:16] <jepler> .. and it's why we groan everytime norbert makes a change in 2.6 and in master.
[13:47:38] <cradek> yeah, in particular, get the bugfixes from stable into development branches
[13:47:52] <jepler> because it's unneceesary; and if done uncarefully (for instance, a blank line in a different spot each time), it can cause a conflict that must be resolved.
[13:48:23] <mozmck> interesting, I had not thought about some of that.
[13:49:55] <seb_kuzminsky> hostmot2-firmware 0.8.13 fixes the permissions problems that Roguish pointed out yesterday (and the hm2 buildbot even worked)
[13:50:43] <seb_kuzminsky> with 0.8.10 (what's on wlo now), the firmware dirs & files all have 0 group & other permissions, so users can's ls in /lib/firmware/hm2/$BOARD to see what firmwares they have
[13:50:53] <seb_kuzminsky> and they can't read the .PIN files, i think?
[13:51:14] <seb_kuzminsky> so i'm going to push 0.8.13 from the hm2-buildbot to wlo, unless anyone objects
[13:51:45] <seb_kuzminsky> no changes to the vhdl between the two
[13:53:05] <pcw_home> mesaflash is pretty close to being able to make .pin files from hardware
[13:53:47] <Tom_itx> no need for xilinx webpack?
[13:54:21] <pcw_home> thats a bit of a tall order...
[13:54:22] <Tom_itx> or is that just on the newer cards like 5i25?
[13:54:30] <pcw_home> all cards
[13:54:45] <Tom_itx> does it launch webpack command line or something?
[13:55:29] <pcw_home> pin files are just the config text report (mesaflash can read the IDROM and make one)
[13:56:00] <cradek> cool!
[13:56:06] <cradek> and yay for the buildbot
[13:56:11] <Tom_itx> as usual...
[13:57:10] <pcw_home> also the latest mesaflash can reload PCI FPGAs like the 5I25 without a reboot now
[13:58:17] <pcw_home> same for Ethernet
[13:58:28] <seb_kuzminsky> cool, that makes the 5i25 about as flexible (firmware-wise) as the anyio boards with plx chips
[13:58:58] <jepler> oh, is 5i25 using a flash chip and stored firmware?
[13:59:08] <pcw_home> Yes
[13:59:11] <Tom_itx> i believe so
[13:59:18] <seb_kuzminsky> and it implements the pci interface on the fpga, right?
[13:59:20] <cradek> we have mesaflash 3.0.0 in our apt repo
[13:59:25] <pcw_home> yes
[13:59:42] <seb_kuzminsky> instead of in a dedicated pci-device-chip like the 5i20 and friends
[14:00:54] <pcw_home> mesaflash cheats, it saves the BAR and command registers, asks the FPGA to reconfig itself, then restores the BAR and command regs
[14:02:10] <jepler> Cheaper to buy a bigger FPGA than a distinct PCI interface chip, I guess?
[14:02:45] <ssi> the s6 series fpgas are pretty inexpensive
[14:05:07] <jepler> yeah
[14:07:49] <jepler> I see that mesa has their own PCI vendor ID
[14:08:17] <Tom_itx> do they charge for that like USB does?
[14:08:56] <jepler> I dunno
[14:09:08] <Tom_itx> USB is like 2K or more
[14:11:52] <pcw_home> Ours is not official (its 9K/year)
[14:12:44] <jepler> hmm, PLX 9030 will set you back $33ea qty100
[14:12:55] <jepler> no wonder you'd love to eliminate it from your BOM
[14:13:36] <pcw_home> XC6SLX9 -TQ144 is ~$9.00
[14:14:19] <jepler> Is there IP required for the PCI interface?
[14:14:39] <Tom_itx> http://www.pcidatabase.com/vendors.php?sort=id
[14:15:40] <CaptHindsight> if I need to have the Z-axis on a mill track the surface of the material and adjust for variations to that the Z cutting depth is always at some set depth from the surface of the material vs a preplanned plane, is there an easy way to input an offset signal to do this?
[14:16:06] <jepler> CaptHindsight: this is what the "offset" component is intended for
[14:16:14] <jepler> man 9 offset
[14:16:25] <CaptHindsight> but the offset is dynamic and on the fly
[14:16:29] <jepler> offset is added from in to get out, and subtracted from fb-in to give fb-out
[14:16:37] <jepler> yes, offset has an offset pin
[14:17:22] <jepler> you may want to use e.g., limit3 so that what would otherwise be a step change in your offset is applied over time with a trapezoidal velocity profile
[14:18:05] <cradek> how do you measure the workpiece?
[14:18:31] <Tom_itx> you'd probably probe it
[14:18:39] <CaptHindsight> could be a laser micrometer
[14:18:50] <cradek> I'd try to just put the offset in the gcode then
[14:19:02] <CaptHindsight> it's moving at several inches per second
[14:19:05] <cradek> depends how planar it is
[14:19:37] <CaptHindsight> so I'm not actually cutting but I used a simple example to explain
[14:19:57] <CaptHindsight> the +- might be a few mm
[14:20:32] <ssi> jepler: hm I wonder if the thc component should be redone to use offset
[14:21:12] <ssi> I've had an ongoing problem with thc component where it seems like it tries to remove the offset as a step change, and it causes lost motion in my Z axis
[14:21:45] <ssi> I hacked the component to fix it, and I think somewhere along the line I lost those changes, or I didn't successfully fix it in the first place, cause it's definitely either still doing it or back to doing it
[14:22:51] <jepler> ssi: :-/
[14:23:16] <ssi> there was some discussion about it on the list a few days ago
[14:23:33] <ssi> and I feel like I'm being gaslit cause I'm not sure anyone agrees that my conclusion about the way it's written is valid ;)
[14:23:35] <jepler> I have seen some discussions, haven't tried to follow them in detail
[14:24:10] <ssi> https://github.com/sittner/linuxcnc/blob/master/src/hal/components/thc.comp
[14:24:13] <ssi> look at line 116
[14:24:26] <ssi> when the torch is off, and the torch is moving up
[14:24:48] <ssi> it subtracts z_diff, which is the entire difference between motion planner position and the "faked" position
[14:25:03] <ssi> if that's a quarter inch, it'll try to make a quarter inch position change in one thread cycle
[14:25:07] <ssi> at least that's my impression
[14:25:21] <ssi> I changed it to remove the correction_vel per cycle until the offset is gone
[14:26:56] <jepler> It looks like z_diff is supposed to be on the magnitude of the distance the machine moved in the last servo cycle
[14:26:59] <jepler> z_diff = z_pos_in - last_z_in;
[14:27:16] <ssi> ok I may be misunderstanding then
[14:27:49] <ssi> either way; the specific problem I'm having is that when the torch moves up after a cut finishes, the Z motor stalls audibly, and my home position creeps down the axis over time
[14:27:56] <seb_kuzminsky> ok, the 0.8.13 hm2 firmwares (with the fixed file permissions) are on wlo
[14:28:04] <ssi> I have my soft limits set hundreds of inches beyond where the axis actually ends or else it'll fault on a program with lots of pierces
[14:28:17] <mozmck> ssi: your acceleration may simply be too high.
[14:28:28] <ssi> I suppose that's possible
[14:28:32] <jepler> ssi: I see
[14:28:38] <ssi> I'll have to try dropping it absurdly low and seeing if it's still an issue
[14:28:38] <mozmck> especially since it does it only on the up direction
[14:29:03] <ssi> it'll jog at max speed in the up direction no problem
[14:29:22] <mozmck> lubrication can help too if it needs it.
[14:29:43] <cradek> does the thc cause extra lift while the head is lifting at the end of a program? if so, that'll try to go faster than jogging will
[14:29:45] <mozmck> is jog speed set to max vel?
[14:29:51] <jepler> yeah, in one direction (offset > 0, I think) it's going to basically balance out the motion with undoing-of-offset
[14:30:13] <jepler> in the other direction, it's going to move twice as far, which means it uses twice the accel and twice the velocity
[14:30:15] <ssi> cradek: at the end of the cut, the thc component sees an upward move with the torch off, and removes the offset
[14:30:29] <cradek> which direction is the offset it's removing?
[14:30:35] <ssi> could be either
[14:30:45] <cradek> so it could be trying to go faster than the jog, right?
[14:30:52] <ssi> yeah I guess so
[14:30:58] <ssi> but shouldn't the accel/velocity limits prevent that?
[14:31:11] <ssi> I guess not, since the component bypasses it
[14:31:15] <cradek> no, because you're messing those up, right
[14:31:27] <ssi> so what you're getting at is my limits should be 50% what the axis will tolerate
[14:31:36] <ssi> to account for the offset removal doubling the jog speed
[14:31:58] <ssi> also I suppose I could change the post to use a G1 move instead of a G0 move
[14:31:58] <jepler> well, if my superficial reading of the code is right, I'd try setting Z accel and vel to 50% what they are now and see what happens
[14:32:02] <ssi> yeah
[14:32:04] <ssi> I'll try that tonight
[14:32:06] <cradek> I don't know if 50% is right, but whatever extra the component causes should be subtracted from your set constraints
[14:32:33] <cradek> jepler: what makes you say 50%?
[14:32:57] <jepler> cradek: because z_diff = z_pos_in - last_z_in;
[14:33:03] <ssi> well if you're jogging an inch, with an inch offset, at max velocity, it'll try to get 2" in the time that the motion planner would go 1"
[14:33:08] <ssi> so twice the velocity
[14:33:09] <ssi> yes?
[14:33:20] <jepler> so it will change the offset by +- as much as the Z axis moves +
[14:33:35] <jepler> when it changes by -z_diff, it goes 0% as fast; when it changes by +z_diff it goes 200% as fast
[14:33:38] <cradek> ok, does sound like doubling
[14:33:53] <jepler> but I wanna keep stressing that this is a superficial impression of what the code's doing
[14:34:08] <ssi> your superficial impression seems more accurate than my superficial impression :)
[14:34:32] <jepler> you'll also get a big step change when changing 'enable', since it'll add or subtract all of offset all at once
[14:35:06] <jepler> well, add or no longer add..
[14:35:07] <ssi> yeah I see that
[14:35:20] <jepler> big thunk and lost position there
[14:35:46] <PCW> "<jepler> Is there IP required for the PCI interface? "
[14:35:48] <PCW> no non-hm2 IP used
[14:36:09] <jepler> PCW: very nice
[14:37:48] <PCW> A target only PCI interface is pretty simple
[14:38:13] <jepler> but my impression from you is that you're the kind of guy who would sit down and write a PCI interface just for fun
[14:38:37] <PCW> Yeah probably
[14:39:02] <jepler> I mean that in a positive way
[14:39:17] <PCW> :-)
[14:41:18] <jepler> PCW, micges: about 1 run in 20, I get:
[14:41:19] <jepler> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
[14:41:19] <jepler> hm2_eth: ERROR: receiving packet: Resource temporarily unavailable
[14:41:19] <jepler> hm2_eth: No ethernet board found
[14:41:57] <jepler> actually, 3 out of the last 20 times, so 1 in 7
[14:42:02] <PCW> hmm thats funny, how is the port setup
[14:42:29] <jepler> it's a PCI-E Intel gigabit nic, direct connected to the 7i80
[14:42:38] <PCW> I have never seen that on my setup
[14:42:41] <jepler> interface is configured like this on the linux side:
[14:42:41] <jepler> auto eth1
[14:42:41] <jepler> iface eth1 inet static
[14:42:41] <jepler> address 192.168.1.1
[14:43:26] <PCW> I put mine off in left field = 10.10.10.10
[14:44:14] <ssi> I gotta get me an ethernet mesa card to toy with
[14:44:15] <jepler> I'm using the default IP address on the 7i80
[14:44:35] <jepler> ssi: Hopefully the driver will be merged to our master branch next week...
[14:44:39] <ssi> sweet :D
[14:45:23] <jepler> ssi: do you have stepgen acceleration and velocity limits on your plasma machine?
[14:45:30] <PCW> what does 'auto' mean sounds dangerous
[14:45:30] <ssi> yes, they're 20% above the axis limits
[14:45:42] <jepler> PCW: auto means "ifup at boot time"
[14:47:19] <PCW> yeah ideally you would like to ensure that linuxcnc owns the particular port (so no other say broadcast traffic get routed through it)
[14:47:47] <jepler> yeah, I remember talking about that the other day
[14:48:29] <jepler> so here's what tcpdump said when I got 'error: receiving packet'
[14:48:29] <jepler> 14:29:30.950778 ARP, Request who-has 192.168.1.121 tell 192.168.1.1, length 28
[14:48:32] <jepler> 14:29:30.950983 ARP, Reply 192.168.1.121 is-at 00:60:1b:11:80:37, length 50
[14:48:35] <jepler> 14:29:30.950990 IP 192.168.1.1.54854 > 192.168.1.121.27181: UDP, length 4
[14:48:38] <jepler> 14:29:30.951261 IP 192.168.1.121.27181 > 192.168.1.1.54854: UDP, length 16
[14:49:17] <jepler> so the reply does come...
[14:50:16] <jepler> but it's well after the requested timeout of 10 microseconds set in hm2_eth.c:init_net
[14:50:42] <PCW> ARP related?
[14:50:56] <jepler> the fact that it had to do ARP may be relevant .. my test setup forcibly removes any cached arp entry before starting
[14:51:06] <jepler> sudo arp -d 192.168.1.121; halrun e2.hal
[14:51:50] <ssi> how does the mesa card get its ip?
[14:52:01] <jepler> ssi: several options
[14:52:07] <PCW> probably the startup should ping the 7I80 and make a static arp entry and remove it on exit
[14:52:11] <jepler> ssi: I'm using the factory default, statically assigned 192.168.1.121
[14:52:47] <PCW> (that would eliminate the MAC field in the config line)
[14:53:47] <jepler> PCW: there is code that tries to set a permanent ARP entry but I don't think it's effective
[14:54:15] <jepler> hm, here's another potential problem
[14:54:24] <jepler> well, it ties in with "other software accidentally sending packets on dedicated interface"
[14:54:28] <jepler> 14:34:51.232785 IP6 fe80::6a05:caff:fe26:ce88.5353 > ff02::fb.5353: 0 PTR (QM)? 121.1.168.192.in-addr.arpa. (44)
[14:54:50] <jepler> who knows why, trying to resolve the IP address as a name sent an IPv6 DNS request over the dedicated interface
[14:54:57] <PCW> thats not good
[14:55:00] <cradek> eww
[14:55:11] <cradek> I bet tcpdump did it
[14:55:15] <cradek> use -n
[14:55:25] <ssi> reverse dns lookup?
[14:55:43] <jepler> actually, that one popped up when I invoked 'arp', which also tried to resolve the address to a name
[14:55:48] <jepler> FF02::FB port 5353 is "multicast DNS"
[14:57:14] <jepler> and these days, every interface gets a "link-local ipv6 address" by default
[14:58:05] <jepler> sudo sysctl net.ipv6.conf.eth1.disable_ipv6-1
[14:58:07] <jepler> sudo sysctl net.ipv6.conf.eth1.disable_ipv6=1
[14:58:43] <cradek> it would be nice if you could use bpf or similar to just allow the traffic you want
[14:58:46] <jepler> anyway, confirmed -- the attempt to set a permanent ARP fails
[14:58:47] <jepler> ioctl SIOCSARP: Invalid argument
[15:02:08] <jepler> .. and there's no code to remove the arp entry at shutdown
[15:04:32] <PCW> well that will add some jitter...
[15:07:01] <PCW> not quite as bad as Windows however, which silently drops UDP packets if the ARP cache entry has expired
[15:12:30] <skunkworks> I have ipv6 disabled for the nic I use with the 7i80..
[15:16:40] <CaptHindsight> jepler: what kernel version are you using on your Exynos Chromebook?
[15:25:20] <jepler> CaptHindsight: whatever google shipped. 3.8.11 apparently.
[17:15:30] <CaptHindsight> https://www.osadl.org/Combined-latency-plot-of-all-RT-systems.qa-latencyplot-allrt.0.html?latencies=&showno=
[17:17:09] <CaptHindsight> https://www.osadl.org/Latency-plot-of-system-in-rack-7-slot.qa-latencyplot-r7s8.0.html BBB
[17:20:23] <CaptHindsight> https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs7.0.html ARM Freescale i.MX6 @996 MHz
[17:24:03] <CaptHindsight> https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs8.0.html ZYNQ Zedboard
[18:53:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 868074c 06hostmot2-firmware 10debian/gencontrol deb: fix control file Description syntax * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=868074c
[18:53:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 195552e 06hostmot2-firmware 10debian/rules deb: use dh for binary-indep and clean targets * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=195552e
[18:53:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master ebb4c5d 06hostmot2-firmware 10debian/compat deb: bump debhelper compat level to 7 * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=ebb4c5d
[20:12:59] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 6692770 06hostmot2-firmware 10debian/copyright deb: link to copyright, don't reproduce * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=6692770