#linuxcnc-devel Logs

Dec 22 2017

07:36 AM linuxcnc-build: build #1328 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/1328 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
07:38 AM linuxcnc-build: build #2458 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/2458 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
07:42 AM linuxcnc-build: build #1329 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/1329 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
08:01 AM skunkworks: https://www.youtube.com/watch?v=NcibPZH-6xY
08:01 AM andypugh: Pumakins:
08:02 AM skunkworks: andypugh, Shouldn't you be working?
08:03 AM andypugh: I have been talking to Rudy du Preez (who did the 5 Axis TCP configs and the 5 axis documentation). While looking at the Posemath issues (recently addressed) he noticed that the Pumakins config and the Pumagui model had different geometry, and so could never work properly.
08:03 AM andypugh: He has fixed it all, and sent me a tar.gz file. Is it possible to apply the fixes under his name?
08:04 AM andypugh: skunkworks: Our plant has closed for Christmas. I am not at work again until the 3rd. I am not allowed in even if I wanted to.
08:06 AM skunkworks: cool - we are closed next week - it will be nice
08:06 AM skunkworks: hope to get a lot of projects done
08:19 AM cradek: andypugh: you can specify --author= when you git commit
08:20 AM cradek: I think you'd say --author="Real Name <email@goes.here>"
08:21 AM cradek: ... if he already has some commits in our history it'd be best if you match that existing author spelling if appropriate
08:39 AM andypugh: It looks like Dewey committed his previous work
08:54 AM andypugh: I don’t know whether to submit Rudy’s fixes to 2.7 or 2.8.
08:55 AM andypugh: It sort of belongs in 2.7, but depends on the master-only fix made to Posemath.
09:20 AM cradek: I guess we'll have to see what seb thinks about that?
10:08 AM seb_kuzminsky: posemath is used by lots of important code, not just pumakins
10:09 AM seb_kuzminsky: does this tarball change parts of posemath that are not widely used?
10:09 AM cradek: andypugh: could you maybe make it into a pull request so we can see it? (sorry you were given such a hard format to work with)
10:10 AM andypugh: I think it only changes the parts that we agreed were broken.
10:10 AM andypugh: (and which have been fixed in master)
10:12 AM seb_kuzminsky: yes, a PR would be most helpful
10:12 AM cradek: is it just changing the rpy functions? I thought those were not used outside pumakins
10:14 AM seb_kuzminsky: cscope to the rescue!
10:29 AM andypugh: Hmm. Rudy says “ Posemath has also been changed as discussed (matZyxConvert and matRpyConvert)."
10:31 AM andypugh: Ah, OK, both got changed.
10:43 AM andypugh: So, I have my owb fork on Github. But it is months out of date.
10:43 AM andypugh: How can I get that up to date prior to pushing these changes to it to create a pull request?
10:44 AM andypugh: (not that I actually know how to push to my own fork either)
10:45 AM andypugh: Maybe I need to start by cloning my own repo to a different git directory.
11:19 AM andypugh: I can’t see any way to make a PR without creating a feature branch on linuxcnc.
11:21 AM seb_kuzminsky: andypugh: here's what i'd do
11:21 AM seb_kuzminsky: make a local clone of the linuxcnc github repo
11:21 AM seb_kuzminsky: add your github repo as a remote in that local clone
11:22 AM seb_kuzminsky: fetch your github repo into your local repo
11:22 AM seb_kuzminsky: push the linuxcnc master and 2.7 branches to your github repo
11:22 AM seb_kuzminsky: create a local feature branch off 2.7
11:22 AM seb_kuzminsky: unpack rudy's tarball on top of it
11:23 AM andypugh: Yes, you are very much saying “If you want to get to there, I wouldn’t start from here"
11:23 AM seb_kuzminsky: then 'git status' and 'git diff' will show you what the tarball changes
11:23 AM seb_kuzminsky: (that's assuming rudy's tarball is based on 2.7, if it's based on master then start your local branch from master)
11:24 AM seb_kuzminsky: git commit the stuff that rudy changed, and push your feature branch to your github repo
11:24 AM seb_kuzminsky: then you can open a pr from your feature branch in your github repo to master or 2.7 in the linuxcnc github repo
11:25 AM andypugh: https://xkcd.com/1597/
11:27 AM andypugh: Unfortunately I am already in the position where I have Rudy’s stuff on top of 2.7 as a commit in a local clone of linuxcnc/linuxcnc then I have my own fork (andypugh/linuxcnc) on github 2057 commits behind master.
11:28 AM andypugh: You do rather seem to be suggesting the same as xkcd. “delete the project and download a fresh copy”
11:30 AM andypugh: I am rather surprised that Github can tell you that your fork is 2057 commits behind, but the only way to issue a “pull” command to it is to re-clone the whole thing to create a command line on your local machine.
12:02 PM cradek: if that works it looks pretty great to me
12:02 PM cradek: but it depends on the rpy changes to work right?
12:02 PM andypugh: Not really. It was a bunch of stuff that he noticed while looking at the RPY stuff
12:04 PM cradek: then we oughta be able to take it in 2.7 I bet. (did you try it?)
12:04 PM andypugh: I would say that it could probably go into 2.7, if it can merge OK into 2.8 configs, which is by no means obvious.
12:04 PM andypugh: No, I haven’t tried it.
12:04 PM cradek: oh yeah, didn't think about that
12:04 PM andypugh: As it only actually afffects a sim config I think it is low risk, wherever it goes.
12:06 PM andypugh: cherry-pick failed.
12:13 PM andypugh: So, if we put the stuff in 2.7 we won’t be able to merge 2.7 into master. And the changes won’t fit in 2.8
12:20 PM seb_kuzminsky: andypugh: i didn't know your starting state, my guide was what i would do if starting from nothing
12:21 PM seb_kuzminsky: that PR for 2.7 looks sane (though i haven't looked at the diff in any detail yet)
12:21 PM seb_kuzminsky: the merge from 2.7 to master might be hairy because of ja issues, but that's ok
12:21 PM seb_kuzminsky: i see that it doesn't touch posemath, i thought that was where this all started?
02:14 PM andypugh: Posemath has already been fixed (https://github.com/LinuxCNC/linuxcnc/commit/5724d8f59996a6a176a5c2d0e82b1650c3dac4cc )
02:14 PM andypugh: seb_kuzminsky: ^
02:29 PM seb_kuzminsky: in master, but not in 2.7
02:30 PM seb_kuzminsky: but maybe that's fine
03:11 PM seb_kuzminsky: hm, i should have maybe done this test before merging:
03:11 PM seb_kuzminsky: load puma.ini, home, hit Run, get this error:
03:12 PM seb_kuzminsky: linear move on line 31 would exceed joint 2's positive limit
03:15 PM seb_kuzminsky: but that also didnt work before the merge so at least it's not worse
03:23 PM andypugh: rene-dev: Had some thoughts about that
03:24 PM rene-dev: yes, all the vismach configs are wrong...
03:24 PM rene-dev: vismach needs to connect to pos-cmd, not motor-pos-cmd
03:24 PM rene-dev: because they use imidiate homing
03:27 PM rene-dev: try homing multiple times, you robot will look wired after a while :D
04:29 PM KimK: Is it OK to add new pinfiles, bitfiles, etc., to the hostmot2 repo? Or is the rule, "Build whatever you need yourself, but don't disturb the repo"? (I ask because it appears nothing new has been added to master since April 2016).
04:39 PM seb_kuzminsky: KimK: pinfiles and bitfiles are generated from the source code in that repo, so they should not be checked in
04:39 PM seb_kuzminsky: if there are modifications to the hm2 source code, that should be considered for inclusion
04:40 PM andypugh: If by “pinfile” you mean “PIN_xyzabc.vhd” then those could be added, I think.
04:40 PM andypugh: Especially if they are likely to be useful (support a specific BoB, for example)
04:57 PM seb_kuzminsky: oh yeah, pinfiles are source, they belong
05:14 PM KimK: OK, thanks, Seb, thanks, Andy. In that case, I will work on adding PIN_4x7I44_96.vhd and PIN_3x7I44_72.vhd. I might need some help later, I'll let you know.
05:16 PM seb_kuzminsky: just ask :-)
05:19 PM KimK: While I have you guys on the line, I have 7i69's (SmartSerial dual Opto-22 24's) that have older firmware S14H1. Should I do anything about this, and if so, what and how?
05:25 PM seb_kuzminsky: KimK: i think you can upgrade them using mesaflash, but i've never worked with smartserial stuff
05:28 PM rene-dev: seb_kuzminsky do you want to do the change with the pos command fix? or shall I make a pull request?
05:29 PM rene-dev: all the vismach configs are affected
05:30 PM rene-dev: so for the loopback link joint.0.motor-pos-fb to joint.0.motor-pos-cmd
05:30 PM rene-dev: and J0pos needs to be joint.0.pos-cmd
05:32 PM rene-dev: and I think the scale can go away
05:45 PM andypugh: KimK: Anything after v14 is currently OK
05:46 PM andypugh: But, if you download the related file from Mesa, put the new firmware in /lib/firmware and run the included shell script it should be semi-automatically uploaded.
05:47 PM andypugh: You can’t update _remote_ firmware with mesaflash, you need to do it inside a HAL session. But the script does that.
05:48 PM KimK: andypugh: And is S14H1 equivalent to 14.1 or something? Oh, well, if it's easy to do en masse, then I probably should upgrade them, right?
05:49 PM andypugh: If linuxCNC complains at boot time, then update. Otherwise there might not be any real gain.
05:50 PM KimK: OK, I'll try it later and let you know. Thanks very much!
05:50 PM andypugh: But, it might be worth it if PCW has updated the firmware since we noticed that a lot of the parameter directions are wrong.
05:51 PM KimK: I'll download the file and look it over.
06:03 PM seb_kuzminsky: rene-dev: i'd love a PR, thank you
06:15 PM KimK: andypugh: There is a V15 for the 7i69 available in the download. But /lib/firmware/ seems to be full of system stuff. And /lib/firmware/hm2/ seems to have only control card folders, no daughter cards. What do you recommend?
06:16 PM andypugh: it belongs in /lib/firmware/hm2 Just make the right folder for the card
06:17 PM KimK: OK, thanks, will do.
09:02 PM jepler: The /lib/firmware location is only *required* for cards that have to be programmed each time you start linuxcnc, like the venerable 5i20. If it's something you program with mesaflash once, there's no restriction on where the bitfile can be on the system where you're running mesaflash.
09:07 PM seb_kuzminsky: and 7i43
09:18 PM jepler: ok, maybe if I understand what andypugh said correctly, this kind of updating also has to be in /lib/firmware
09:18 PM jepler: sorry for the confusion
10:10 PM seb_kuzminsky: /lib/firmware is for stuff that we load from kernel space
10:10 PM seb_kuzminsky: mesaflash doesnt have the limitation