Back
[08:04:54] <skunkworks> PCW, seems to be running 1khz just fine
[08:05:04] <skunkworks> (days so far)
[08:46:15] <jepler> let's see how the forum fares upgrading from 14.04 to 16.04 (operating on a copy of its virtual machine)
https://www.digitalocean.com/community/tutorials/how-to-upgrade-to-ubuntu-16-04-lts
[08:48:17] <cradek> hey you could use illegit zfs now
[08:49:09] <jepler> oh gee thanks for reminding me
[08:55:03] <jepler> mysql_upgrade: [ERROR] 1007: Can't create database 'performance_schema'; database exists
[08:55:06] <jepler> mysql_upgrade failed with exit status 5
[08:55:08] <jepler> dpkg: error processing package mysql-server-5.7 (--configure):
[08:55:11] <jepler> subprocess installed post-installation script returned error exit status 1
[08:55:14] <jepler> hm this doesn't seem good
[08:56:10] <jepler> and then the upgrader process asked to send the error, I said yes and *that* crashed
[08:56:13] <jepler> AttributeError: 'bytes' object has no attribute 'encode'
[08:56:26] <jepler> >>> looks like you're trying to write python3, where they screwed up everything about strings. continue? N/N
[08:56:31] <cradek> thanks obama
[08:58:11] <jepler> and now that I've rebooted, the front page of the website says: setStart($startTime, $startMem)->mark('afterLoad') : null; // Instantiate the application. $app = JFactory::getApplication('site'); // Execute the application. $app->execute();
[08:58:28] <jepler> that was not something you could qualify as a success
[09:30:52] <cradek> jeez, yay for snapshots
[09:33:06] <jepler> the major version of php seems to have changed, the upgrade didn't install new corresponding packages, and now everything's busted.
[09:33:15] <jepler> so yeah throw this one away and wait until I have a weekend to devote to it
[09:47:07] <skunkworks> Yeck.. Thanks for keeping up on it.
[13:55:01] <CaptHindsight> so it appears that if one ARM core (#0) is used for RT Linuxcnc and the others (#1-3 or #1-7) for software rendering. that AXIS and window movement is quite zippy
[13:55:24] <PCW> skunkworks: the Zotac (using a N3150 CPU) has also been running at 1KHz for a few days now and seems OK (4.4.7-RT16, OSADL config)
[13:55:37] <CaptHindsight> undecernable from x86
[13:56:43] <CaptHindsight> indiscernible
[13:58:37] <PCW> Not great latency wise (160 usec) but with position sample retiming its not really an issue
[14:00:05] <skunkworks_> that reminds me - I have to make sure the dpll is turned on in the matsurra
[14:02:42] <PCW> No sure there's a 7I80HD servo config with DPLL, I need to remake a lot of the 50 pin Ethernet configs
[14:03:37] <skunkworks__> I thought it was a hal setting..
[14:04:02] <PCW> it is, but the DPLL module needs to be there
[14:04:31] <skunkworks__> ah - so I would need to update the 7i80.
[14:06:13] <PCW> what config are you using now?
[14:06:50] <PCW> (guessing svss6_8 something_
[14:09:34] <skunkworks__> I would have to look.. It has the 7i48 and 7i44
[14:11:53] <PCW> probably 7i80hd_16_svss6_8.bit
[14:16:28] <jepler> CaptHindsight: unmodified, rtapi/hal are written to bind to the highest CPU number, not the lowest one. did you modify linuxcnc to get RT on #0 instead?
[14:43:07] <PCW> skunkworks, should you read back:
[14:43:09] <PCW> http://freeby.mesanet.com/7i80hd_16_svss6_8D.bit
[15:06:36] <JT-Shopp> I've got something out of wack on my gantry attempt, the motors run but don't stop
http://gnipsel.com/files/emc/Gantry/
[15:07:15] <JT-Shop> both motors spin but are slow to get up to speed
[15:13:03] <CaptHindsight> jepler: preempt_rt on ARM, just wanted to show that 1 core if Linuxcnc with the other for software rendering
[15:14:08] <CaptHindsight> so to be even more clear it appears that if one ARM core (#3 or #7) is used for RT Linuxcnc and the others (#0-2 or #0-6) for software rendering. that AXIS and window movement is quite zippy
[15:21:19] <PCW> at the minimum, this is wrong
[15:21:20] <PCW> net axis.1.command pid.1.output => gantry.0.position-cmd
[15:22:27] <PCW> PID outputs should only be wired to stepgen velocity inputs
[15:25:26] <PCW> take a look at:
[15:25:27] <PCW> freeby.mesanet.com/gantry.zip
[15:25:28] <PCW> at least for basic connctions
[15:25:36] <PCW> connections
[15:29:17] <JT-Shop> thanks
[15:30:22] <seb_kuzminsky> JT-Shop: here's the config for the gantry machine at my local hackspace:
http://highlab.com/~seb/linuxcnc/bes-shopbot/
[15:30:33] <seb_kuzminsky> it works pretty well
[15:30:55] <seb_kuzminsky> there's a branch in that repo named "ja", which has the joints_axes conversion of the config, it works even better
[15:31:06] <JT-Shop> cool
[15:31:09] <seb_kuzminsky> incremental world-mode jogging! wooooo
[15:32:47] <JT-Shop> I don't see the ja branch
[15:32:58] <seb_kuzminsky> oops, hold on
[15:32:59] <JT-Shop> I did find the hey page
[15:33:19] <seb_kuzminsky> try now
[15:33:22] <seb_kuzminsky> it's named "ja"
[15:33:45] <PCW> does the JA branch do gantry homing correctly?
[15:34:22] <seb_kuzminsky> sure, for some value of "correctly"
[15:34:35] <seb_kuzminsky> it doesn't do the synchronized-homing trick cradek's been talking about
[15:34:55] <PCW> well no increase in crabbing during homing
[15:35:04] <JT-Shop> I refreshed this page a couple of times but no ja
http://highlab.com/~seb/linuxcnc/
[15:35:16] <seb_kuzminsky> i think it homes in the same way master does
[15:41:54] <seb_kuzminsky> JT-Shop: uh, well, i dont know what i have to do to make the git repo inside ~seb/linuxcnc/bes-shopbot be accessible :-(
[15:41:58] <seb_kuzminsky> sorry
[15:42:24] <seb_kuzminsky> i just ran the update_ini script and fixed (by hand) its obvious mistakes
[15:45:57] <seb_kuzminsky> JT-Shop: here:
https://github.com/SebKuzminsky/bes-shopbot/tree/ja
[15:46:19] <JT-Shop> that worked :)
[15:46:21] <JT-Shop> thanks
[15:47:02] <seb_kuzminsky> there's probably tons of out-of-date info and just plain mistakes all over
[15:48:56] <PCW> fixed a minor PID constant issue:
[15:48:58] <PCW> http://freeby.mesanet.com/gantry.zip
[15:49:40] <PCW> that should just work on the 7I92 (may need to change the card name)
[15:50:43] <JT-Shop> thanks
[15:52:22] <jepler> scathing "un-review" of pine64
http://hackaday.com/2016/04/21/pine64-the-un-review/
[15:53:31] <jepler> > The hard part is getting the software working, getting the documentation together, and fostering a community that isn’t stumbling in the dark trying to get this board to work. This is where the Pine64 fails. The forums are a mess right now, and the comments on the Kickstarter campaign aren’t much better.
[15:53:44] <jepler> > The software support and documentation is so sparse, I literally can not get into a Linux terminal. With a day sunk into setting up the Pine, I only have a picture of a Pirates of the Caribbean desktop that came on a distribution produced by someone completely unrelated to the Pine team. This isn’t just me, either; a few of the Hackaday Overlord devs gave the Pine a shot, too. The results were i
[15:53:51] <jepler> nconclusive.
[15:55:02] <PCW> At least it loaded and I was able to jog around, did not attempt homing as I don't have the hardware
[15:55:03] <PCW> that may take some tweaks...
[16:20:25] <JT-Shop> yea, I'm building a show and tell gantry to test with as soon as I get it running
[16:25:47] <PCW> the gantry comp homing violates machine accel so depends on reasonable stepgen accel limits
[16:31:40] <PCW> I think a proper stepgen would do this:
[16:31:42] <PCW> its incoming position command accel limits are set to machine limits +say 0.25% to allow minor math/ timing errors
[16:31:43] <PCW> its feedback accel limit is set to the machine limits +20% for internal PID headroom
[16:31:45] <PCW> as it stands there are still some robustness issues
[16:33:21] <PCW> that is if the position command exceeds the stepgens accel limits, bad things happen (your nice first order linear feedback loop goes all to hell)
[16:45:22] <JT-Shop> I'm very happy to report the Y axis is running correctly now, thanks
[16:54:17] <PCW> the real question is will 2 switch homing work
[16:57:51] <JT-Shop> testing that now
[16:58:57] <PCW> I tested the step part, (didnt want to hear any more from Mr dead in the water with 7I92)
[17:11:41] <JT-Shop> I hear you
[17:12:21] <JT-Shop> guess I need to rig up a couple of micro switches using pyvcp inputs gives a limit error
[18:35:14] <JT-Shop> wire up the switches and see what happens
[19:10:05] <JT-Uspace> hmm, I get hit limit in home state 7 and joint 1 on limit switch error as soon as the first one contacts a home switch... test more tomorrow
[19:31:23] <PCW> hmm are you hal-wiring the limit switches _though_ the gantry component? there should be only one common home signal from the gantry comp to motion
[19:55:22] <PCW> here's Charles example homing setup:
[19:55:24] <PCW> https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Probotix/Comet.hal#L105-L111