#linuxcnc-devel | Logs for 2018-11-07
Back
[00:04:42] <linuxcnc-build> build #5681 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:05:03] <linuxcnc-build> build #694 of 1630.rip-stretch-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:06:17] <linuxcnc-build> build #695 of 1610.rip-stretch-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:07:36] <linuxcnc-build> build #5678 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:07:54] <linuxcnc-build> build #4893 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:08:06] <linuxcnc-build> build #2832 of 1903.clang-wheezy-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:10:45] <linuxcnc-build> build #3355 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:10:49] <linuxcnc-build> build #3839 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:11:11] <linuxcnc-build> build #3840 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:11:20] <linuxcnc-build> build #2306 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:11:32] <linuxcnc-build> build #4041 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:11:35] <linuxcnc-build> build #3509 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:11:36] <linuxcnc-build> build #2308 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:12:17] <linuxcnc-build> build #2306 of 1500.rip-jessie-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:12:25] <linuxcnc-build> build #2308 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:15:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley commented on issue #523: Sorry i answered on the pr #525 - but here is a copy:... 02 https://github.com/LinuxCNC/linuxcnc/issues/523#issuecomment-436507472
[00:17:34] <linuxcnc-build> build #2831 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:17:35] <linuxcnc-build> build #5700 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>
[00:20:15] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15rene-dev pushed 2 new commits to 06master: 02 https://github.com/LinuxCNC/linuxcnc/compare/ad81328d8db5...5a63d03110ec
[00:20:15] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 14a734c9f 15Rene Hopf: Revert "fix compiler warnings in tp.c"...
[00:20:15] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 145a63d03 15Rene Hopf: Revert "Merge branch 'feature/reverse-run-master2'"...
[00:22:51] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley pushed 2 new commits to 06qt5vcp_py2: 02 https://github.com/LinuxCNC/linuxcnc/compare/cfe9c1b9eddd...b05b1d6e0410
[00:22:51] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 14733217d 15Chris Morley: qtvcp -remove 2 second delay when closing.
[00:22:51] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 14b05b1d6 15Chris Morley: qtvcp -add tooloffset and macrotab as widgets...
[00:34:35] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley closed issue #470: Missing axis INI setting with trivkins should default to joint settings or cause a warning 02 https://github.com/LinuxCNC/linuxcnc/issues/470
[00:52:57] -!- hazzy has quit [Ping timeout: 252 seconds]
[01:09:10] -!- ve7it has quit [Remote host closed the connection]
[01:38:33] -!- c-log has quit [Ping timeout: 268 seconds]
[01:43:13] -!- c-log has joined #linuxcnc-devel
[02:19:52] -!- skunkworks has quit [Ping timeout: 268 seconds]
[02:21:03] -!- skunkworks has joined #linuxcnc-devel
[04:21:04] <linuxcnc-build> build #2388 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[04:27:08] <linuxcnc-build> build #4526 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[04:32:21] <linuxcnc-build> build #4526 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[04:32:39] -!- JT-Shop has quit [Read error: Connection reset by peer]
[04:33:22] -!- jthornton has quit [Read error: Connection reset by peer]
[04:33:22] -!- JT-Fshop- has quit [Read error: Connection reset by peer]
[04:34:48] <linuxcnc-build> build #3356 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[04:35:09] -!- jthornton has joined #linuxcnc-devel
[04:36:42] -!- JT-Fshop- has joined #linuxcnc-devel
[04:36:44] -!- JT-Shop has joined #linuxcnc-devel
[04:37:20] <linuxcnc-build> build #3095 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:05:25] <linuxcnc-build> build #2354 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:22:37] <linuxcnc-build> build #2786 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:31:58] <linuxcnc-build> build #3098 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:40:40] <linuxcnc-build> build #1767 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:42:13] <linuxcnc-build> build #1769 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:44:36] <linuxcnc-build> build #1656 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:47:08] <linuxcnc-build> build #1655 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:49:56] <linuxcnc-build> build #550 of 4031.deb-stretch-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:54:15] <linuxcnc-build> build #550 of 4030.deb-stretch-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[06:41:23] -!- selroc has joined #linuxcnc-devel
[06:51:45] -!- selroc has quit [Quit: Leaving]
[07:08:35] -!- jthornton has quit [Read error: Connection reset by peer]
[07:08:36] -!- JT-Shop has quit [Read error: Connection reset by peer]
[07:08:36] -!- JT-Fshop- has quit [Read error: Connection reset by peer]
[07:08:59] -!- JT-Fshop- has joined #linuxcnc-devel
[07:08:59] -!- jthornton has joined #linuxcnc-devel
[07:08:59] -!- JT-Shop has joined #linuxcnc-devel
[07:16:08] -!- hazzy has joined #linuxcnc-devel
[07:42:03] -!- skunkworks has quit [Ping timeout: 252 seconds]
[08:37:01] -!- skunkworks has joined #linuxcnc-devel
[10:23:16] <jepler> I have considered making the "supported architecture" check say "no" for all architectures in a couple of these branches, but it would create an additional speed bump when merging that branch back in to master so I resist.
[10:23:30] <jepler> still, I wish cmorley would take some steps to avoid this noise for us
[10:23:41] <jepler> seb_kuzminsky: all the same, thanks for fixing it so we can hear linuxcnc-build again
[10:31:08] <mozmck> I think I'm going to merge external offsets...
[10:48:58] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15mozmck pushed 1 new commit to 06master: 02 https://github.com/LinuxCNC/linuxcnc/commit/349512cd5bee6357697076156190989eaf28e9bd
[10:48:58] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 14349512c 15Moses McKnight: Merge branch 'dgarr/external_offsets'
[10:55:16] <mozmck> Shouldn't branches which have been merged be deleted at some point?
[10:57:26] <seb_kuzminsky> mozmck: yes, they should be deleted
[10:57:55] <seb_kuzminsky> jepler: it looks easy to fix the packaging problem in cmorley's branch
[10:58:38] <mozmck> hi seb. I'm really trying to work towards a freeze and then release soon. I will probably need some pointers on how to go about some of that!
[10:58:49] <seb_kuzminsky> awesome!!! woooooo!!!!!!
[10:58:59] <seb_kuzminsky> i'm always happy to help with that part
[10:59:49] <mozmck> Great - thanks! My question on branches comes partly from looking through 252 branches on github :-)
[11:00:21] <seb_kuzminsky> the part i was sucking at was deciding when new features were good enough to merge, so i'm glad you folks have been making those decisions and moving forward
[11:01:12] <seb_kuzminsky> i don't mind managing the release branches and tagging and packaging and buildbotting and stuff
[11:01:38] <mozmck> Yeah, I don't reckon I'm any good at it, but I'm relying on others input mostly.
[11:02:09] <seb_kuzminsky> do you have a feel for how the stability of master is at this point? i've only been paying a little bit of attention
[11:02:15] <mozmck> branching and tagging is easy, but the buildbot stuff is different.
[11:02:27] <seb_kuzminsky> nearly all my machines run 2.7, and the few 2.8~pre machines haven't been updated for months
[11:03:38] <mozmck> From what I can tell from not using it myself - It seems really stable. Numbers of people are running with external_offsets for plasma and have for a while.
[11:04:30] <mozmck> Reverse run is one other feature I'm looking at - but it looks like Rob is having to do some stuff in the TP to handle it better, so I don't know if it should go in yet or wait until after the release.
[11:05:59] <sync> I would put it in
[11:06:16] <seb_kuzminsky> there are a *lot* of new features in 2.8 already, and it's been... over 3 years since 2.7.0, so my recommendation would be to push out a release without waiting for more things
[11:07:13] <seb_kuzminsky> if there's stuff that's ready to go, that you approve of and think is mostly stable, and that has a developer willing to help stabilize it the rest of the way, then sure merge it, but i'd say don't hold the release for things that are not yet ready
[11:07:18] <seb_kuzminsky> that's what the next release is for ;-)
[11:07:54] <mozmck> True. I don't plan to wait long on that one.
[11:08:54] <seb_kuzminsky> looks like rene merged and then reverted reverse-run last night?
[11:09:22] <mozmck> sync: do you know more about reverse run? I see that Rob made a commit yesterday "Added groundwork for reverse run in TP execution"
[11:09:55] <mozmck> seb_kuzminsky: yes - there were some conflicts. I think Rob made that commit after rene reverted but not sure.
[11:10:30] <sync> I know that they talked about it
[11:11:40] <skunkworks> I think rene might be working on it..
[11:11:57] <skunkworks> I was supposed to find him a config but I think it is at work
[11:12:43] <mozmck> hi skunkworks!
[11:17:12] <skunkworks> Hi!
[11:21:43] <mozmck> oh... I think that commit I saw from Rob was an artifact of Rene merging reverse-run
[11:22:28] <mozmck> So maybe it is just a more minor conflict now
[13:10:05] -!- cradek has quit [Changing host]
[13:10:05] -!- cradek has joined #linuxcnc-devel
[13:10:05] -!- mode/#linuxcnc-devel [+v cradek] by ChanServ
[13:31:39] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley pushed 1 new commit to 06qt5vcp_py2: 02 https://github.com/LinuxCNC/linuxcnc/commit/d5ad58188b8d3bb331cf4cab326cde206ff0206c
[13:31:39] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 14d5ad581 15Chris Morley: qtvcp -fix packaging error
[14:12:46] -!- ve7it has joined #linuxcnc-devel
[16:17:57] <mozmck> Hmm, was reverse-run in dgarr's external-offsets branch??? I'm playing with merging reverse-run and it acts like it is already there!
[16:25:22] <rene_dev_> mozmck thats just git
[16:25:29] <rene_dev_> because I reverted it
[16:25:47] <rene_dev_> It looked ok, but then problems came up
[16:26:25] <mozmck> Hi rene_dev_ how is that? I made a test branch off of master, then tried to merge reverse-run-master2 into it and it said it was already up to date.
[16:27:20] <rene_dev_> that is how git works. I merged it, so its in. git doesnt know about the revert
[16:27:31] <rene_dev_> but I think I know how to fix it now.
[16:27:49] <rene_dev_> https://github.com
[16:28:04] <mozmck> I see - that's kind of strange though. Does git just go by the commit numbers?
[16:29:25] <rene_dev_> thats just how it works. lets say you merge some stuff, and ten undo it by hand. git doesnt know about the undo
[16:29:51] <rene_dev_> you can just checkout the repo after my merge
[16:31:22] <mozmck> Interesting. How do you get the changes back then if you want to merge them in later?
[16:32:55] <mozmck> will do
[16:32:56] <rene_dev_> revert the revert :D
[16:33:18] <rene_dev_> I didnt want to force push
[16:33:25] <mozmck> yeah
[16:33:41] <rene_dev_> that can cause bad things
[16:39:06] <rene_dev_> but reverse run seems to be stable, many pepole seem to be using it
[16:39:42] -!- andypugh has joined #linuxcnc-devel
[16:40:05] <mozmck> hi andypugh
[16:40:20] <rene_dev_> the pepole in the forum seemd to be very happs about that
[16:40:52] <andypugh> I haven’t looked today
[16:41:07] <andypugh> Hi mozmck
[16:41:18] <rene_dev_> https://forum.linuxcnc.org
[16:42:27] <andypugh> Oh, I hadn’t seen those go in.
[16:42:39] <rene_dev_> they are not, I messed up badly :D
[16:42:59] <andypugh> But, still, I normally expect an email
[16:43:27] <andypugh> But EO went in
[16:43:34] <rene_dev_> yes
[16:43:39] <mozmck> andypugh: I was looking through branches, and I noticed that your multispindle branch has commits not in master?
[16:43:54] <andypugh> Has it?
[16:43:57] <mozmck> I merged EO this morning - hope it goes well!
[16:44:11] <andypugh> I rebased and combined a few things before merge
[16:44:33] <mozmck> andypugh: on github it says the branch is 25 commits ahead of master...
[16:44:54] <mozmck> I was looking around seeing if there were already merged branches we could delete!
[16:45:07] <rene_dev_> joint axis can be deleted
[16:45:36] <andypugh> mozmck: Curious.
[16:45:55] <mozmck> rene_dev_: ah, that's true.
[16:51:57] <andypugh> I am not sure what is going on there, but those 25 commits are all of multispindle.
[16:52:37] <andypugh> It all went in, but possibly all the commit hashes changed when I re-factored into fewer commits.
[16:53:25] <mozmck> oh, maybe so.
[16:54:19] <rene_dev_> yes, thats possible
[16:54:21] <mozmck> Well, I won't delete the branch, but if you think it is ok maybe you can. I'll probably delete JA
[16:55:11] <andypugh> I just deleted the branch
[16:55:27] <andypugh> https://github.com
[16:55:44] <andypugh> We could possibly delete some of the 15 year old stale branches too :-)
[16:56:05] <mozmck> That's what I was thinking :-)
[16:56:24] <andypugh> Though those are so old perhaps they have historical value
[16:56:32] <mozmck> yeah
[16:57:06] <andypugh> I have only recently remebered the G71/G72 branches
[16:57:55] <andypugh> I can’t even recall where we were.
[16:58:19] <Tom_L> are those intended as lathe cycles?
[16:58:19] <andypugh> Oddly we have docs for a feature that doesn’t exist, which is a novelty
[16:58:24] <andypugh> Yes
[16:58:35] <Tom_L> as is g76?
[16:59:31] <rene_dev_> https://www.youtube.com
[17:00:18] <rene_dev_> https://www.youtube.com
[17:01:21] <rene_dev_> like that?
[17:02:46] <andypugh> https://github.com
[17:03:33] <mozmck> who was it saying they had a g71 but wouldn't release it?
[17:03:43] <rene_dev_> 2 years old, wow
[17:04:24] <rene_dev_> well, they have to, dont they?
[17:04:48] <mozmck> no - especially if they don't distribute it.
[17:04:51] <andypugh> It doesn’t matter who said that, we already have one
[17:05:27] <andypugh> https://github.com
[17:05:29] <mozmck> Seemed like his had some really nice benefits - but I can't remember the details. Maybe it wasn't much.
[17:05:45] <andypugh> But that one doesn’t do pockets or, as far as I recall, radius comp
[17:06:20] <andypugh> But, I did a remap as an algorithm check in Python.
[17:06:50] <rene_dev_> mozmck well, they do distribute it. anyway, I can look what they use.
[17:07:07] <andypugh> The plan was to merge the Python code in to the C++ version and then use the generic radius comp code.
[17:07:28] <mozmck> I don't think it was someone with tormach - unless maybe tormach paid him for his code?
[17:07:46] <andypugh> But, well, we didn’t. I think Ben Potter got bored, or didn’t see the point once there was a remap to do it.
[17:08:54] <rene_dev_> andypugh one of the tormach guys also has a near-a-car, but cant remember who
[17:09:58] <andypugh> Zultron / John Morris.
[17:10:26] <andypugh> Because his great-grandfather was Carl Neracher, the designer of the Ner-a-Car
[17:11:42] <rene_dev_> ah, yes. he was the one.
[17:12:13] <rene_dev_> would g71 not be a good project after multi spindle? :D
[17:13:32] <andypugh> Yes
[17:13:46] <andypugh> It’s on the list
[17:14:01] <andypugh> But I would like to see 2.8 out first.
[17:19:00] <rene_dev_> yes
[17:19:40] <rene_dev_> I think we should come up with a roadmap for 2.8, and decide on a date for feature freeze...
[17:20:31] <andypugh> I suggested a few weeks ago that we should freeze now (including reverese run) and aim to release by new-year
[17:21:00] <andypugh> But I don’t know how keen CMorley is to get qtvcp in
[17:22:27] <mozmck> andypugh: you mean including reverse-run in 2.8 or freezing it out?
[17:22:52] <andypugh> Talking about roadmaps, can anyone make any sense of the last post here? I really don’t even understand the question: https://www.model-engineer.co.uk
[17:23:04] <andypugh> mozmck: Including it
[17:24:04] <mozmck> I'm for including it if the problems rene found can be resolved soon and aren't major. I thought it was up to date with master already.
[17:28:00] <mozmck> I *think* he is saying that tormach had to spend money to make a usable system that their users don't have to read lots of docs to use, because linuxcnc lacks "good functional mileposts"
[17:28:21] <mozmck> tell him that linuxcnc is not a highway and therefore doesn't need mileposts.
[17:29:12] <andypugh> I really don’t understand what a “functional milepost that users can choose” is
[17:29:25] <mozmck> If he means a good "roadmap", I'm not sure how that would help any users.
[17:29:47] <mozmck> yeah, I don't know.
[17:31:14] <sync> I think he means milestones aka revisions that "work" and are documented
[17:31:17] <sync> but idk
[17:32:13] <mozmck> That would be strange because each revision has worked and had documentation.
[17:32:55] <sync> maybe they were not to his liking
[17:32:56] <cradek> andypugh: I don't think that question is asked in good faith
[17:35:20] <andypugh> No, that’s mainly why I didn’t reply.
[17:35:41] <andypugh> I suspect he is not a LinuxCNC user.
[17:46:38] <rene_dev_> he is probably better off with mach3
[17:56:54] <andypugh> We are better off with him using Mach3
[18:01:56] -!- ve7it has quit [Remote host closed the connection]
[18:03:33] -!- ve7it has joined #linuxcnc-devel
[18:03:35] <CMorley> andypough: I'm ok with qtvcp not being included in 2.8 -provided my don't wait another three years for 2.9
[18:03:47] <CMorley> thanks for asking though
[18:04:26] <CMorley> I am interested in opinions of pncconf - i'm considering removing it.
[18:04:38] <andypugh> Hmmm
[18:04:51] <rmu> what is missing from qtvcp
[18:04:56] <andypugh> I can see why, but it does seem to be in-demand
[18:05:42] <CMorley> rmu: time to find bugs and a good fully functional production ready screen
[18:06:29] <CMorley> andypugh: yes when it works it is _very_ helpful to users but it is _very_ difficult to make sure it works.
[18:08:47] <andypugh> A version that queried the actual hardware and got the pin names that way might be less of a maintainance headache, but a ton of work to write.
[18:09:33] <CMorley> yes. but it is still a lot of work to maintain for new hardware.
[18:10:10] <rene_dev_> I think the approach of pncconf and stepconf is not the best
[18:10:12] <andypugh> for new interfaces, yes, but as far as looking to see what it finds?
[18:10:30] <rene_dev_> of generating hal files, that can then not be edited
[18:10:35] <CMorley> anyways i'm tired of if and i guess it's too difficult for others to help - as i see John was making his own to the 7i96...
[18:11:15] <andypugh> Yes, I rather wish that he had tried to help with pncconf rather than write a one-off tool
[18:11:17] <CMorley> Yes pncconf can query the boards right now..it's a slightly hidden option
[18:11:26] <jthornton> CMorley: I made that just as a simple way for users to get up and running with the 7i96
[18:11:40] <CMorley> Oh I understand john
[18:11:41] <rene_dev_> would be better to have generic hal files for the most common setups, that are then overwritten by user changes, or ini settings
[18:11:57] <andypugh> rene_dev_: We have _some_ of that
[18:12:09] <rene_dev_> like the stmbl hal files, or the way some of the xhc stuff works
[18:12:22] <jthornton> one thing I did was make the wizard read the ini file
[18:12:26] <rene_dev_> after all, that is the idea of the hal pulling data from the ini
[18:12:46] <andypugh> The XHC #include files messed up the update_ini script.
[18:13:03] <andypugh> Well, to be fair, I failed to test update_ini with #include files
[18:14:14] <rene_dev_> I did a retrofit of another weiler a few days ago, with a 7i77. and there are no example configs. took me an hour to even get the basic stuff working
[18:14:46] <CMorley> did you use pncconf?
[18:15:08] <rene_dev_> no, I could not figure out how to use it
[18:15:18] <CMorley> interesting
[18:15:21] <jthornton> that's what I use an example from pncconf for 7i77
[18:15:28] <rene_dev_> 7i92+7i77, analog servo
[18:16:15] <jthornton> I think the one I have is a 5i25 7i77
[18:16:32] <rene_dev_> well, I know how stuff works, and can come up with a hal file quickly, but I can imagine that its very difficult for pepole when they get started
[18:16:41] <rene_dev_> should not make a difference...
[18:17:09] <CMorley> it doesn't in pncconf- either are possible
[18:19:51] <rene_dev_> I guess Im just not very good with GUIs
[18:20:24] <CMorley> lol
[18:21:04] <CMorley> to be fair - pncconf could be made to be simpler but then you lose options - it's a balance.
[18:21:34] <CMorley> also it was orignally made when hardware was much simpler and i was a much worse programmer
[18:21:45] <rmu> i did try to make pncconf work with 7i90 connected via spi on the raspberry ;-)
[18:22:07] <rmu> had some success
[18:22:25] <CMorley> really - i don't think the 7i90 is actually supported
[18:22:43] <rmu> no, not really...
[18:23:48] <CMorley> One of the real problems with it is, in general the devs don;t use it, so it never gets tested much when it's released - hence always buggy
[18:23:56] <rene_dev_> :D
[18:24:32] <CMorley> rmu: did you use the discovery option/
[18:24:40] <rmu> i tried
[18:25:11] <rmu> IMO it is the only sensible way to do things, connect to whatever mesa device you have, and try to make sense of the HAL pins that appear
[18:25:27] <jthornton> what does the discovery option do?
[18:25:31] <CMorley> yes it's true
[18:25:41] <CMorley> it queries the actual hardware
[18:26:08] <jthornton> does it do that with a readhmid?
[18:26:31] <CMorley> It uses mesaflash to read everything
[18:26:36] <rmu> i hit some roadblocks, it could query the 7i90 (with hacked-in SPI stuff), but then i got stuck somehow and gave up... there were some other problems like non-working MESA firmware at that time
[18:26:46] <jthornton> that's what I meant, I don't have it on this pc
[18:26:47] <CMorley> so it require mesaflash, which we don't include IIRC
[18:27:12] <jthornton> I added that to the 7i96 wizard in two flavors 32bit and 64bit
[18:27:21] <jthornton> I use it to get some info
[18:27:51] <jthornton> not sure if anyone has actually used it yet lol
[18:28:00] <CMorley> Well John please add all the other cards, so I can get rid of pncconf... :)
[18:28:25] <jthornton> I was thinking about doing one for each family of cards...
[18:29:58] <rmu> i think a bigger roadblock for mesa users is trying to figure out which firmware to use... names like SVSS6_8 or SSSVST8_8_8 are not very intuitive and I at least didn't find a real reference besides the VHDL sources
[18:30:00] <CMorley> rmu: yes the discovery option helps the user for sure, but the problem then becomes it will find hardware that pncconf doesn't support
[18:30:30] <jthornton> actually I have some started for the 7i76E and the parallel port
[18:31:00] <jthornton> Chris how do you translate the mesaflash info into pins?
[18:31:01] <CMorley> You don't think speconf works well for the parport?
[18:31:23] <CMorley> very dificulty
[18:31:33] <rmu> why don't you just start up HAL and look at the pins of the hm2 driver?
[18:31:56] <jthornton> well mine read the ini file so a bit better I think
[18:32:02] <rmu> that should be easier than parsing whatever mesaflash returns
[18:32:10] <CMorley> you can look in the source. it's worse because I needed to convert it what pncconf expected from the XML file
[18:32:30] <CMorley> read what from the INI file?
[18:32:55] <jthornton> all the configuration information, I add some at the bottom for the wizard
[18:33:31] <jthornton> I can open an ini and it sets everything in the wizard and if something has changed in the ini it gets that right
[18:34:17] <CMorley> I am missing something - we were talking mesa hardware info used to make an configuration - so there would be no INI file
[18:34:32] <jthornton> sorry jumping around a bit
[18:35:41] <CMorley> anyways for pncconf - if I had three other people helping it all might have happened but i'm interested in other things now :)
[18:36:13] <CMorley> i guess my qiestion is pull it out now before 2.8 or after.
[18:37:03] <jthornton> if your going to pull it before a release would be better, you could put it in a branch for those that use it
[18:37:06] <CMorley> rmu - reading using mesaflash get you more info then reading just the HAL pins
[18:37:48] <CMorley> pulling it out after allow someone to make a replacement in the mean time
[18:38:03] <jthornton> ah yes
[18:41:55] <jthornton> I wonder if I should add my 7i96 configuration tool to master?
[18:42:32] <CMorley> Can't really hurt... it's option to use
[18:43:17] <jthornton> I'll have to try and figure out where to put it in the directory structure
[18:44:45] <CMorley> src/emc/usr/intf would be the place I think
[18:45:44] <jthornton> ok I'll make a branch in the morning and see if I can get it all sorted out
[18:45:54] <jthornton> good talking with you again Chris
[18:46:23] <rene_dev_> rmu hal pind dont tell you the hardware pins
[18:46:25] <CMorley> you bet John!
[18:47:21] <jthornton> time to start some chow
[18:47:44] <CMorley> mozmck: migth be nice to add mesaflash to linuxcnc
[18:48:19] <jthornton> yes for sure that would be nice
[18:48:37] <andypugh> I find the bitfile names fairly intuitive:-)
[18:48:46] <CMorley> ttyl guys
[18:49:12] <jthornton> see you later
[18:49:14] <andypugh> SSSVST8_8_8 means “SmartSerial / Servo / Stepper and 8 of each.
[18:50:07] <jthornton> you will have to elaborate a bit on how you got that lol
[18:50:52] <Tom_L> especially for a noob :)
[18:51:30] <andypugh> SS = Smart Serial. SV = Servo, ST = Stepper. then the numbers are the numbers of each
[18:51:56] <andypugh> TP = three-phase PWM (7i39 etc) and RV = Resolver (7i49)
[18:52:16] <andypugh> UA + UART
[18:52:58] * jthornton takes notes
[18:53:13] <Tom_L> some are obvious but others not so much
[18:55:26] <rmu> andypugh: but "servo" doesn't say much at all, there are different pinouts
[18:56:28] <andypugh> Typically SV == 7i33 pinout. The more recent cards tend to have the actual card name. (7i65 for example)
[18:56:33] <Tom_L> not too bad for a descriptive filename though
[18:56:34] <rmu> and "SSSV6_36" hat 18 stepgens and nothing else IIRC
[18:58:08] <andypugh> https://github.com
[18:59:23] <andypugh> That’s 18 muxed encoders (so 36 encoders total) and 6 smart-serial channels.
[18:59:24] <rmu> yeah, but flashing the file with SSSV6_36 with SPI for 7i90 has only 18 stepgens ;)
[18:59:51] <andypugh> Something wrong there, it shouldn’t have any stepgens.
[19:00:38] <rmu> perhaps i messed up my table, i made the effort some time ago to dump the HMID of all 7i90 firmwares
[19:00:38] <andypugh> (should point out that this is just what I have picked up over the years, I have no actual connection to Mesa)
[19:01:18] <Tom_L> and here i thought you were one of their main debuggers :)
[19:01:42] <andypugh> Not at all, I am one onf the main bug-writers
[19:12:30] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jethornton created 06mesa-7i96 at 1491fa2d9 (+0 new commits): 02 https://github.com/LinuxCNC/linuxcnc/commits/mesa-7i96
[21:15:01] <mozmck> I think we have mesaflash on the iso - but it might be nice to include with linuxcnc somehow. Or even just have it packaged in the repo and information on it.
[21:51:15] -!- andypugh has quit [Quit: andypugh]
[22:00:25] -!- Roguish has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
[22:03:56] <jepler> yes, mesaflash should be available for any architecture that linuxcnc packages are
[22:04:00] <jepler> from linuxcnc.org.
[22:11:34] <pcw_home> rmu: there are possibly some missnamed 7I90 files around (I think my build script didn't notice if one failed to build (too big) so you ended up with last bitfile that built)
[22:17:30] <pcw_home> (and 36 stepgens will not fit in a 7I90)
[22:57:50] -!- hazzy1 has joined #linuxcnc-devel
[22:57:53] -!- hazzy has quit [Ping timeout: 276 seconds]
[22:57:54] hazzy1 is now known as hazzy
[22:58:39] <CMorley> andypugh:Looking a linuxcnc status program in master - looks like spindle info is not displaying right. Hope you are good with tcl :)