Back
[08:40:43] <skunkworks> zlog
[09:28:31] <seb_kuzminsky> cradek: a user on the forum asked about a limitation in running M-codes with cutter comp on:
http://www.linuxcnc.org/index.php/english/forum/20-g-code/28770-m62-m65-and-m66-cause-error-while-g42-is-on#54917
[09:29:16] <seb_kuzminsky> the limitation was added in commit e0c96fbe, "merge concave_comp2 branch: new cutter compensation algorithm"
[09:37:23] <cradek> I think you could add handling of those to the interp queue and flush.
[09:37:53] <cradek> cutter comp has to queue (an arbitrary number of) moves now that inside corners are allowed
[09:38:12] <cradek> so if ccomp is on, you can't just issue these kinds of things when you encounter them
[09:38:32] <cradek> so the answers are 1) disallow, or 2) queue and handle them with the motions
[09:40:31] <cradek> for these output codes 2) does not seem tricky at all
[09:55:35] <pcw_home> I was reading a bit about Linux Ethernet drivers and the odd timing issue
[09:55:36] <pcw_home> with the RTK 8111 may just be that Interrupt coalescing is turned on
[10:05:31] <seb_kuzminsky> M62/63 are "set/clear output synched with motion", M64/65 are "set/clear immediately", does that affect anything?
[10:06:50] <seb_kuzminsky> holy indentation, batman
[10:07:51] <seb_kuzminsky> oh, i see, there are separate bits & set/clear macros for the synched-with-motion outputs and the immediate outputs
[10:09:10] <cradek> I don't understand the immediate ones. they are probably stupid.
[10:09:25] <seb_kuzminsky> looks like the synced set/clear goes in the interp_list already
[10:10:20] <seb_kuzminsky> "immediate" also goes on interp_list
[10:11:26] <seb_kuzminsky> oh, there's a flag in the message Task sends to Motion called "now", which differs between them
[10:13:24] <seb_kuzminsky> the flag's used by Task, not Motion, sorry
[10:14:33] <seb_kuzminsky> oh, and by Motion
[10:15:36] <seb_kuzminsky> hm ok, so it looks like interp already does option 2 from above, and we should try just removing the check that disallows it
[10:16:30] <seb_kuzminsky> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/task/emccanon.cc;h=ca403037e667f9c7f4a9e6c1435d95ca2fe1bc34;hb=refs/heads/master#l2982
[10:17:29] <cradek> no - interp_queue, not interp_list
[10:17:32] <cradek> bbl
[10:17:40] <seb_kuzminsky> thanks for your help! seeya later
[10:18:07] <seb_kuzminsky> oh man, there is so much i dont know about linuxcnc
[10:19:31] <mozmck> I'm curious why there are 6 joints_axes# branches?
[10:19:45] <seb_kuzminsky> mozmck: they're successive rebases onto master
[10:19:59] <mozmck> What does that mean?
[10:20:02] <seb_kuzminsky> the older ones are kept around for historical reasons, only the latest one (ja6) is live
[10:20:13] <mozmck> They have been merged into master?
[10:20:18] <seb_kuzminsky> there are two ways to combine commits from two branches in git: merge and rebase
[10:20:30] <seb_kuzminsky> we normally use the merge way in linuxcnc
[10:20:39] <seb_kuzminsky> but we're trying out rebase for joints_axes
[10:20:50] <mozmck> ah, and rebase loses history so you keep the old branch?
[10:20:57] <seb_kuzminsky> exactly
[10:21:20] <mozmck> I see. So what does the joints_axes branch do and will it ever be finished and in use?
[10:21:57] <seb_kuzminsky> ja intends to clean up some of the confusion inside linuxcnc between joints and axes
[10:22:14] <seb_kuzminsky> ja6 achieves much of that, but introduces some bugs in the process
[10:22:26] <mozmck> I see.
[10:22:29] <seb_kuzminsky> no one is currently working on fixing those bugs, so development has pretty much stalled
[10:23:29] <mozmck> I'm looking for information on setting up a dual motor gantry, which led to mention of the jaX branches.
[10:23:43] <seb_kuzminsky> yeah
[10:24:04] <seb_kuzminsky> multi-motor gantries dont work all that great in our main branches
[10:24:32] <mozmck> Is there a good solution for that yet? Sychronized homing and no jogging in free mode?
[10:24:36] <mozmck> hmm.
[10:24:57] <seb_kuzminsky> you can do it, i ran a dual-motor gantry on a 5 foot by 10 foot shopbot with linuxcnc 2.5 a few years ago
[10:25:08] <seb_kuzminsky> it had its quirks for sure
[10:25:25] <mozmck> hmm, quirks are not good for our use case :)
[10:25:47] <seb_kuzminsky> synchronized homing (independent of ja) is started in the branch called cradek/synchronized-homing
[10:26:08] <seb_kuzminsky> i'd be happy to help out if you want to test it & finish it
[10:26:13] <seb_kuzminsky> (i'm not sure what state it's in)
[10:26:50] <seb_kuzminsky> err, the branch is in cradek's repo, not the main git.linuxcnc.org one
[10:27:00] <mozmck> I see that with gantrykins it puts you in free after homing and you have to switch modes to jog.
[10:27:40] <mozmck> Yes, I will need to get something working.
[10:27:50] <seb_kuzminsky> i don't know of a good reason for any machine to stay in free mode after homing
[10:27:55] <mozmck> You mean this one?
[10:27:56] <mozmck> http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/synchronized-homing
[10:28:00] <seb_kuzminsky> yep
[10:28:22] <mozmck> http://linuxcnc.org/docs/html/man/man9/gantrykins.9.html
[10:29:05] <mozmck> It also says that World-mode only supports continuous jogging, which is a problem...
[10:29:51] <mozmck> So maybe that's why it goes to joint mode - so you can do incremental jogging?
[10:30:22] <seb_kuzminsky> heh, yeah i added the text about jogging & modes to gantrykins.9 while i was figuring out how to run that shopbot, i guess back in 2011
[10:30:44] <mozmck> I see :)
[10:30:52] <seb_kuzminsky> i wonder how hard it would be to add incremental world-mode jogging
[10:31:04] <mozmck> So can world-mode be changed to allow incremental... you beat me to it!
[10:31:38] <seb_kuzminsky> anything can be done, it just needs someone to do it
[10:32:28] <mozmck> heh!
[10:32:32] <seb_kuzminsky> ;-)
[10:32:40] <mozmck> I might have to start looking into that then here.
[10:37:16] <seb_kuzminsky> cool
[10:37:16] <seb_kuzminsky> bbl
[10:53:37] <cradek> ja has incremental world-mode jogging already
[10:53:57] <cradek> that synchronized-homing does NOT work
[10:54:21] <cradek> it's only interesting if you want to continue developing the idea
[10:54:22] <mozmck> hmm, so what are the bugs in ja then?
[10:54:44] <cradek> I'm not sure, we've done a poor job of keeping track of them :-/
[10:54:50] <mozmck> Well, I definitely need to develop some form of syncronized homing.
[10:55:06] <mozmck> Are the changes in ja pretty large?
[10:55:08] <cradek> it would be awesome if you'd finish it
[10:55:12] <cradek> yes, massive
[10:55:25] <mozmck> Is it something that could be incrementally done in master?
[10:55:31] <cradek> which it?
[10:55:37] <mozmck> the ja changes
[10:55:49] <cradek> I'm afraid that train has sailed
[10:56:33] <cradek> I think you could add synchronized homing to master without having ja first, but having ja first would be better
[10:56:47] <mozmck> hmm
[10:57:13] <cradek> ja seemed pretty broken for me when I tried it on a XYZC machine, I think because the valid axes are nonconsecutive. I expect it to be broken in the current condition for XZ lathes too
[10:57:44] <cradek> I don't know how deep that problem is
[10:58:17] <mozmck> Our customers *mostly* build dual axis gantry machines, and some will be dual axis gantry with a rotary axis as well.
[10:58:27] <cradek> I think ja is actually quite clean - it doesn't have lots of unrelated things stirred together, it's just a big change
[10:59:02] <cradek> by all means please test and report back
[10:59:06] <mozmck> dual motor I mean.
[10:59:12] <mozmck> test ja?
[10:59:34] <cradek> if you want incremental world mode jogging, yes you have to dive in to ja
[10:59:53] <mozmck> Yes, I'll have to start working on that. I need more time - or to use the time I have more wisely...
[11:00:19] <cradek> if you only want synchronized-ish homing, and you don't have index pulses, you could use various stopgaps that people have done
[11:00:44] <cradek> don't we all. the human condition.
[11:01:06] <mozmck> It is pretty much all stepper or servos using step/dir inputs, and so no index homing.
[11:03:05] <pcw_home> index homing should be possible with step/dir
[11:03:47] <pcw_home> as long as the index is long enough for linuxcnc to see
[11:04:46] <mozmck> well, in our case I don't think there is an index on the encoders, and not one that gets back to linuxcnc for sure.
[11:05:14] <cradek> software or hardware stepgen?
[11:05:44] <cradek> people using software stepgen and dual home switches can just do some clever/terrible gating of the step signals
[11:05:52] <mozmck> I think hardware only.
[11:06:25] <pcw_home> Yes I was asked If i could add that to our hardware stepgen but its just too ugly
[11:06:36] <cradek> yeah it's sure a wrong solution
[11:06:44] <mozmck> :) Better to fix the software than a hack like that.
[11:06:46] <cradek> but people who don't have a right solution often want those
[11:07:10] <mozmck> I can understand that
[11:07:46] <mozmck> JT put a shaft through his gantry and used one motor, but that is not an option for us.
[11:07:58] <cradek> pcw_home: would you please send me another H-bridge card to replace the one we blew up at fest? it only needs two channels working, in case that helps you pick a junker for me
[11:08:46] <pcw_home> I was just about to ask (we have a bunch of early rev 7I30s with a patch on the back I could send)
[11:08:49] <cradek> oh there's a web store now - I could even just order one
[11:09:11] <pcw_home> if you dont mind ones with wires on the back
[11:09:27] <cradek> bespoke boards are the best kind
[11:10:35] <cradek> mozmck: if you're serious about working on synchronized homing I would happily send you this hardware I've been carrying around for years
[11:10:36] <mozmck> pcw_home: I presume the 7i80 is ready for production use? preempt-rt only?
[11:10:59] <cradek> actually that offer is open to anybody
[11:11:04] <pcw_home> Yes it has about a year of testing now
[11:11:22] <pcw_home> for PP replacement, the 7I92 is a lot cheaper
[11:11:48] <mozmck> cradek: I'm serious about it. what kind of hardware? We have a couple of gantry machines at the shop, but I work mostly from home (~ 3 miles from the shop)
[11:13:05] <mozmck> pcw_home: thanks - I'll look at the 7i92
[11:13:06] <cradek> it's a shoebox (well, boot box) sized thing that has two servos sliding parallel blocks to two home switches, and encoders with index, all run by a blown-up 7i30
[11:13:22] <cradek> it's a pretend servo gantry
[11:14:24] <mozmck> cradek: hmm, do you have a picture? I may be interested!
[11:14:25] <cradek> we were going to cut grooves and then put uncooked spaghetti between the two blocks for a good test
[11:14:34] <cradek> ummm
[11:17:20] <cradek> aha
[11:17:23] <cradek> http://timeguy.com/cradek-files/emc/2010-10-31_17-52-13_194.jpg
[11:18:08] <cradek> except now it's finished and has home switches and an attached driver board
[11:18:40] <cradek> I forgot there were holes for indicators (in case you want to test final alignment)
[11:20:08] <mozmck> I see! Well, I think I better take a stab at it, and that looks like it might be helpful for testing on the bench.
[11:20:47] <cradek> I'll wait for peter's shipment, then get it working, then get it shipped to you
[11:20:56] <kwallace> That HNC looks like mine - clamps holding parts together and used for tooling storage :)
[11:21:25] <cradek> yep like my jogwheel mounting? it's super deluxe.
[11:21:37] <kwallace> :)
[11:23:03] <archivist> it is hard work counting all the clamps on my "grinder"
[11:23:54] <mozmck> cradek: thanks!
[11:25:26] <cradek> mozmck: do you have some mesa fpga card with the 50 pin connector to run it?
[11:25:52] <mozmck> All I have right now is a 7i80DB
[11:26:03] <mozmck> So I guess not.
[11:26:19] <mozmck> what card would I need?
[11:26:22] <cradek> oh yeah, wrong connectors
[11:27:01] <cradek> any of the old ones, 5i20, 7i43 etc
[11:27:43] <cradek> I have a reworked 7i43 seb gave me, but it seemed dead last time I tried it
[11:27:51] <mozmck> ok
[11:28:08] <cradek> let me work on getting it going again
[11:28:51] <cradek> meanwhile you might be able to set up simulation for the non-index part of it and maybe make some progress that way
[11:29:05] <cradek> we have simulated home switches in some of the sim configs already
[11:29:07] <mozmck> ok. now that I think about it, I may have something that would work with a little effort as well.
[11:29:46] <cradek> I only built this because I want all the homing methods, including index, to work, and I don't really know how to simulate that
[11:29:47] <mozmck> I have a partly finished small table, and I think it is a dual stepper motor gantry.
[11:29:56] <mozmck> Oh, yes.
[11:30:14] <cradek> there are so many homing styles!
[11:31:33] <mozmck> pcw_home: I don't see the 7i92 on the webstore
[11:33:16] <pcw_home> should there by the end of the week
[11:36:02] <mozmck> ah, ok
[11:42:52] <cradek> pcw_home: do you know of any problem where the stepgens in a 5i25 develop a problem after a long run-time or on-time? I have seen a hint of a problem (steppers stalling on rapids when running gcode but not when jogging, not fixed by restarting linuxcnc, fixed by reboot) a couple times
[11:43:32] <cradek> but of course I didn't study it, because I had parts I wanted to make
[11:43:45] <pcw_home> Not that I have heard of
[11:43:49] <cradek> and actually I don't know if the steppers stalled (pulses too fast) or if there were no pulses at all
[11:43:56] <cradek> my bug report sucks, sorry
[11:44:41] <cradek> this is 2.6.x with a custom 5i25 firmware tom? built for me
[11:44:55] <pcw_home> stepgen hardware is basically unchanged for several years
[11:45:30] <cradek> I'm still using position mode, not velocity mode as you might be testing more now
[11:45:50] <pcw_home> pulses too fast would likely cause a following error (unless you have wide limits)
[11:46:19] <cradek> yeah it doesn't ferror, I see the cone move, but the machine doesn't
[11:47:12] <cradek> I think it has always been an X or XY move that fails, while Z still works (so it's a very crashy situation)
[11:47:15] <pcw_home> sounds like an interface issue (I would check the step pin with a scope)
[11:47:24] <cradek> yeah clearly I need to stop and debug when it happens next time
[11:47:50] <cradek> I will try hard to do that instead of HULK HAVE PARTS TO MAKE SMASH BUTTONS UNTIL WORKS AGAIN
[11:47:57] <archivist> any backlash compensation?, not sure that follows a good acceleration curve
[11:48:02] <cradek> no backlash
[11:48:28] <cradek> actually I think rebooting did NOT fix it last time, but turning off the pc did
[11:48:41] <cradek> which really makes me think it's a 5i25+firmware problem
[11:48:53] <cradek> but yeah, need to debug
[11:49:20] <pcw_home> or marginal level problem (thermal)
[11:50:02] <cradek> or power supply something something
[11:50:32] <pcw_home> yeah need to probe around when its not working
[11:50:32] <cradek> I think my step/dir boards have schmitt trigger inputs, and XYZ are all identical
[11:50:54] <pcw_home> are they HC or HCT?
[11:50:56] <cradek> also it's extremely suspicious that running gcode fails but jogging doesn't seem to fail when it's in this state
[11:51:09] <cradek> pcw_home: I don't know
[11:51:19] <archivist> that could also be a symptom of stepper drivers that auto sleep
[11:51:32] <cradek> they don't sleep
[11:51:44] <pcw_home> HC Schmitt triggers would be marginal with ~3V signals
[11:52:06] <cradek> ah is 5i25 3v outputs?
[11:52:21] <pcw_home> Yes
[11:52:48] <pcw_home> so you might try setting step/dir outputs to open drain mode
[11:53:51] <cradek> hm!
[11:54:56] <cradek> gpio.000 and gpio.001 (??) are open-drain but nothing else is
[11:55:28] <cradek> looks like those are enable and spindle-on
[13:52:50] <PCW> Ahh one last thing was messing with latency on Preemt-RT: Fan speed control
[13:53:22] <mozmck> oh, interesting!
[13:53:41] <mozmck> Is that a kernel config option or bios?
[13:53:46] <skunkworks> zlog
[13:53:49] <PCW> BIOs
[13:54:08] <PCW> it looked so innnocent...
[13:58:57] <skunkworks> was that your long read times?
[14:00:13] <PCW> not sure yet but have 4KHz running on E8500 for a full day now with no more than 125 usec worst case read time
[14:00:35] <PCW> not been able to do that before
[14:08:38] <skunkworks> cool
[14:13:16] <PCW> do have to figure out a way of blacklisting the interface so the network mangler cant touch it
[14:49:20] <mozmck> what does the network manager do to the interface that is bad?
[14:59:20] <PCW> if you poke at the network manager icon it pokes at the interfaces ant takes them offline for 100s of ms
[14:59:41] <PCW> not a great thing for real time...
[14:59:58] <mozmck> ah, I see.
[15:01:50] <PCW> especially not great if you are machining something expensive
[18:53:12] <seb_kuzminsky> PCW: you had said earlier there was an sserial bug that you wanted to have micges fix before 2.7.0~pre3, is that the push he did last night/this morning or is there more to come?
[18:56:18] <seb_kuzminsky> i love seeing a long string of commits improving the tests, like this:
https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/spiral-arc-handling-rebase
[18:58:34] <PCW> Thats the one (set sserial.run false if sserial is totally bollixed up)
[19:00:58] <seb_kuzminsky> alright cool
[19:01:01] <PCW> This allows hal logic to deal appropriately with remote I/O failures
[19:01:14] <seb_kuzminsky> that's great
[19:01:55] <seb_kuzminsky> then the last thing for the next pre-release is rob ellenberg's spiral fix, and arceye's spiral tolerance patch
[19:02:27] <PCW> also the X/Y only fix?
[19:02:39] <seb_kuzminsky> rob says his spiral feature branch is passing all the tests now
[19:02:50] <seb_kuzminsky> remind me what the X/Y only fix is please?
[19:03:25] <PCW> acceleration/velocity violations in 2 axis machines
[19:03:50] <seb_kuzminsky> do you have a link?
[19:04:24] <PCW> (I think rob ellenberg added a test)
[19:04:26] <PCW> This was something on the forum
[19:05:05] <seb_kuzminsky> is it part of the spiral-arc work? sam pointed out some acc issue with low-acc Z and high-acc X & Y, and rob fixed it
[19:05:40] <PCW> Yeah I think its fixed as part of that
[19:06:38] <seb_kuzminsky> skunkworks: do you know this issue? can you confirm it's fixed in rob's latest branch?
[19:08:02] <seb_kuzminsky> whoops, bug #402 should be fixed too,
https://sourceforge.net/p/emc/bugs/402/
[19:10:31] <PCW> its neat that I can run PCI and Ethernet on the same hardware with uspace,
[19:10:33] <PCW> a bit surprised someone would try parallel port (though I guess it should work)
[19:10:57] <PCW> just lumpy
[19:11:12] <seb_kuzminsky> bbl
[19:44:46] <skunkworks> that was the main fix was for the xy only config - plus he did a bunch of arc spiral stuff. (I don't understand) :) He did say he has a couple of issues yet to figure out. (thought he would work on it tonight.) (moves taking more time then they should)
[19:49:23] <skunkworks> (and speeding up motion)
[21:31:34] <Tom_itx> when using mesaflash to write a bitfile to a card, do you need to erase before write or just write the file?
[21:32:09] <cradek> I've never erased
[21:32:41] <Tom_itx> have you uploaded different bitfile configurations or the same one?
[21:33:01] <Tom_itx> i'm just used to µC's where you need to erase first
[21:33:20] <Tom_itx> maybe the utility takes care of it for me
[21:33:47] <Tom_itx> i have the command line PCW gave me to load the file..
[21:33:51] <Tom_itx> guess i'll just try it
[22:12:49] <Tom_itx> yeah the utility does an erase before write
[22:18:01] <Tom_itx> must have worked.. was able to readhmid and show the new configuration
