#linuxcnc-devel Logs

Nov 08 2017

08:28 AM JT-Shop: jepler: user karlhe tried to I assume request a password and sent me an email saying I do not get a new password sent
09:00 AM jepler: JT-Shop: I seem to get "invalid security code" from the lost password form every time
09:00 AM JT-Shop: ok
09:01 AM jepler: specifically for "lost password"; "lost username" seems to be OK !?
09:01 AM jepler: it's weird
09:03 AM JT-Shop: that is weird that one works and the other is broken
09:03 AM jepler: exactly
09:06 AM jepler: OK, I believe I've corrected the problem with sending password reset emails
09:07 AM jepler: it wasn't due to yesterday's change, it was due to the change last month to update to the current version of google's captcha
09:07 AM jepler: I had fixed the part for logins, but I didn't realize there was a second part for password reset emails
09:07 AM jepler: and it turns out that while the captcha is displayed for "forgot username", it's not acually checked(!)
09:08 AM jepler: >
09:08 AM jepler: New User Password created and sent to your email address d.k.heinrich@web.de. Please check your email (and if needed your spambox too)!
09:11 AM JT-Shop: thanks for fixing that
09:11 AM jepler: argh I didn't intend to pate their email address
09:12 AM jepler: I'm sad it took so long to find out that was broken, but I'm glad I could fix it.
05:51 PM HomicidalBrainia: Hey guys, I am writing my own machine controller to better understand how they work. I am implementing something similar to HAL used by linuxCNC, but it is different in that I treat input and output pins separately. Input pins are pointers only, while outputs are in essence "signals" which allocate space. The thought behind this is that it should be impossible to connect two outputs to eachother. Is there a reaso
05:51 PM HomicidalBrainia: I am wondering if I am missing something.
05:51 PM seb_kuzminsky: your first comment got cut off - too long
05:52 PM andypugh: LinuxCNC dos not allow you to connect two outputs together.
05:52 PM seb_kuzminsky: "Is there a reaso" ...?
05:52 PM HomicidalBrainia: "Is there a reason it's not done this way with Linux CNC's HAL?"
05:52 PM seb_kuzminsky: ah
05:52 PM HomicidalBrainia: well I am guessing HAL uses code to do a check that to outputs are not connected together
05:52 PM seb_kuzminsky: as andypugh said, we have the same constraint, but implemented differently
05:52 PM seb_kuzminsky: yeah
05:53 PM HomicidalBrainia: I am completely fascinated by linuxCNC
05:53 PM HomicidalBrainia: though my knowledge is mainly from the EMC days.
05:54 PM HomicidalBrainia: The way I am doing it means it won't need code to check/constrain that outputs are not connected to eachother.
05:54 PM HomicidalBrainia: but I have not coded it yet.
05:54 PM HomicidalBrainia: Wondering if LinuxCNC is avoiding some kind of issue that's not obvious
05:55 PM seb_kuzminsky: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/hal_lib.c#L1092
05:55 PM HomicidalBrainia: OK brilliant, that makes sense
05:55 PM seb_kuzminsky: and the HAL_OUT case is just above that
05:56 PM HomicidalBrainia: I have not considered the case for bidirectional data yet, wonder if I'll run into problems there.
05:56 PM seb_kuzminsky: we only use it in a few places, as a kind of handshaking
05:56 PM HomicidalBrainia: Does linuxCNC still use sense plan react model?
05:57 PM seb_kuzminsky: yes, read inputs, process the inputs & g-code program, emit outputs
05:57 PM seb_kuzminsky: is that what you mean?
05:57 PM seb_kuzminsky: that's conventional but not required
05:58 PM HomicidalBrainia: The way I am doing things, I am first generating the trajectories and then sending them to a queue that runs the interpolators. I can see it causing problems for things like rigid taping, or probing
05:58 PM HomicidalBrainia: When I last played with what is now linuxCNC, it did not use a buffer/queue of sorts like that.
05:59 PM seb_kuzminsky: right, when path elements need feedback from the physical system, that queueing can get in the way
05:59 PM seb_kuzminsky: linuxcnc does use queues internally, but not at the point of contact with the machine
06:01 PM HomicidalBrainia: Has anyone stripped down LinuxCNC enough to run on a PIC32MX/MZ series microcontroller? If not, is it under consideration?
06:01 PM seb_kuzminsky: no one has tried that, to the best of my knowledge
06:02 PM seb_kuzminsky: our architecture uses multiple threads and processes, so you'd have to rip that out, or run on a micro with some kind of embedded multithreaded operating system
06:02 PM HomicidalBrainia: I've seen projects like Smoothie, GRBL, etc, but they lack the design philosophy of linuxCNC, which is essentially the correct one.
06:02 PM HomicidalBrainia: Yeah right now I'm using freeRTOS for my machine controller project.
06:02 PM seb_kuzminsky: it sure works well, in the environment it's designed for
06:03 PM seb_kuzminsky: (linuxcnc that is, i know nothing of freertos)
06:03 PM HomicidalBrainia: at this point trying to determine if I'll learn more writing controller from scratch, or adapting linuxCNC to a PIC32MZ.
06:04 PM HomicidalBrainia: if I adapted linuxCNC to PIC32MZ, it might fill a small niche. Just not sure how much people would see value in it.
06:04 PM seb_kuzminsky: i was in your situation a bunch of years ago and i decided to hack on linuxcnc, in place. i wrote device drivers for motion control fpgas, then branched out into other parts of the system
06:04 PM seb_kuzminsky: i've learned a lot that way, and it's satisfying that the work i've done is getting used by lots of folks
06:05 PM HomicidalBrainia: I've been dabbling over the last few years. It is very likely I will commit a lot of time once I get my wife's health stabilized
06:05 PM HomicidalBrainia: I would love to see linuxCNC being used for 3D printers
06:05 PM seb_kuzminsky: it is!
06:06 PM HomicidalBrainia: woah really?
06:06 PM HomicidalBrainia: I've been searching for that kind of thing, could you spare me a link/youtube video?
06:06 PM seb_kuzminsky: i have a mostly-assembled mendelmax all running linuxcnc
06:06 PM seb_kuzminsky: no videos or anything yet...
06:07 PM HomicidalBrainia: well it's good to know at least
06:07 PM HomicidalBrainia: I figured it could be done
06:07 PM seb_kuzminsky: here's the first hit on youtube: https://www.youtube.com/watch?v=X1ZYwggkjlA
06:07 PM seb_kuzminsky: from 2.5 years ago ;-)
06:08 PM HomicidalBrainia: So one of the reasons I'm using a queue for the interpolators is to soften the realtime requirements.
06:08 PM HomicidalBrainia: I wonder if there's a way to incorporate realtime feedback into such a system.
06:08 PM HomicidalBrainia: Right now, I am not doing that, causing around a 20 ms overshoot during homing operations
06:08 PM seb_kuzminsky: ouch
06:09 PM HomicidalBrainia: It's not an issue if I'm homing it slow after the initial search
06:09 PM seb_kuzminsky: have you seen the technique of offloading the realtime requirements from the PC to an FPGA?
06:09 PM seb_kuzminsky: maybe a microcontroller could do that too
06:09 PM HomicidalBrainia: Also the homing code records exact position in realtime, so it's properly homed even after an overshoot.
06:10 PM HomicidalBrainia: but it does require the machine's axes are tolerant of some overshoot.
06:10 PM HomicidalBrainia: yeah that's not a bad idea at all
06:10 PM seb_kuzminsky: right, or tolerant of running into the hard stops
06:10 PM HomicidalBrainia: yup
06:11 PM HomicidalBrainia: I might see if I can get a system that senses feedback, flushes the interpolator queue, replans, and then repopulates the queue.
06:12 PM seb_kuzminsky: in this setup we run "soft realtime" stuff on the linux computer, and it computes waypoints for the hard realtime embedded system at something like 1 kHz
06:12 PM HomicidalBrainia: I really like how linuxCNC has gone through the effort of making the proper distinction between axes and joints.
06:12 PM HomicidalBrainia: ooh that sounds like a good idea
06:12 PM seb_kuzminsky: the embedded system is then responsible for getting each motor to its next commanded waypoint by the end of that cycle
06:12 PM HomicidalBrainia: OK that makes sense
06:13 PM HomicidalBrainia: Man, I really appreciate all your help
06:13 PM seb_kuzminsky: you need consistent configuration between the planner on the PC and the joint controller on the embedded system, so the planner knows how much acceleration and velocity it can ask for
06:13 PM seb_kuzminsky: sure thing :-)
06:13 PM seb_kuzminsky: hi dgarr
06:15 PM HomicidalBrainia: OK so this implies that the trajectory is planned and broken up along those intervals. Mine is planning the entire trajectory at once using a process called "taylor subdivision"
06:16 PM HomicidalBrainia: it successively subdivides the entire trajectory until the deviations from midpoints along the trajectory is below some threshold
06:16 PM HomicidalBrainia: it's also called "bounded deviations"
06:17 PM HomicidalBrainia: not sure if I like the way I am doing it at the moment
06:17 PM HomicidalBrainia: it requires that the forward kins and inverse kins have extremely low round-off error
06:18 PM HomicidalBrainia: It also uses a lot of stack space as it's recursive
06:18 PM HomicidalBrainia: I got the prototype controller up a while ago, you can see it here: https://www.youtube.com/watch?v=qasLhuJFZNU
06:19 PM HomicidalBrainia: it's HAL was hardwired at compile time, the changes I am making now will let it wire up during runtime.
06:22 PM HomicidalBrainia: Time for dinner with the family, I'll hit you guys up again later. Thanks again for letting me pick your brain for a bit.
08:08 PM dgarr: better method for wheel jog accel control: http://www.panix.com/~dgarrett/stuff/accel-fraction.png
08:56 PM linuxcnc-build: build #368 of 1540.rip-jessie-armhf is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1540.rip-jessie-armhf/builds/368 blamelist: Dewey Garrett <dgarrett@panix.com>
09:01 PM linuxcnc-build: build #5184 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5184 blamelist: Dewey Garrett <dgarrett@panix.com>
09:03 PM dgarr: linuxcnc-build: force build --branch=dgarr/jog-accel-fraction
09:03 PM linuxcnc-build: you must provide a Builder, try 'force build [--branch=BRANCH] [--revision=REVISION] [--props=PROP1=VAL1,PROP2=VAL2...] <WHICH> <REASON>'
09:05 PM dgarr: linuxcnc-build: force build --branch=dgarr/jog-accel-fraction 0000.checkin
09:05 PM linuxcnc-build: build forced [ETA 2h27m31s]
09:05 PM linuxcnc-build: I'll give a shout when the build finishes
09:23 PM -!- #linuxcnc-devel mode set to +v by ChanServ
09:46 PM Roguish_ is now known as Roguish
09:56 PM linuxcnc-build: build #369 of 1540.rip-jessie-armhf is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1540.rip-jessie-armhf/builds/369
09:58 PM linuxcnc-build: build #5185 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5185