#linuxcnc-devel Logs

Aug 10 2017

02:38 AM pcw_mesa_ is now known as pcw_mesa
10:42 AM seb_kuzminsky: seems like a good feature to me
11:00 AM archivist: and when is the right time to wean people off setup widgets
11:04 AM pcw_home: I think its arguable that debounce should be put in the low level driver
11:04 AM pcw_home: I know this is contrary to the unixy/halsy do everything with small components orthodoxy
11:04 AM pcw_home: but it would greatly simplify hal files and I think hal file complexity is a "barrier to entry"
11:05 AM archivist: I think stepconf not reading hand edits is a barrier too and its limited knowledge of hal
11:07 AM pcw_home: Yeah its relatively easy to convert GUI checkboxes/valueboxes to boilerplate hal files
11:07 AM pcw_home: the reverse conversion is much harder
11:08 AM jepler: sometimes I wish I could go back in time and not start writing stepconf
11:09 AM jepler: but I was young an idealistic back then
11:15 AM cradek: I like both the extremes of no gui and full gui configurability, and we're currently in some unholy spot between the two
11:22 AM seb_kuzminsky: i think stepconf is good and helpful
11:22 AM seb_kuzminsky: i use it sometimes. it make simple stuff easy
11:23 AM seb_kuzminsky: pcw_home: a drawback with putting debounce of home and limit switches into Motion is that it adds more configuration knobs to Motion, even in situations where no debounce is needed
11:24 AM seb_kuzminsky: we could default those knobs to "do not debounce" so the behavior is like it is now, but it would still show up in the documentation and perhaps steepen the learning curve there
11:24 AM seb_kuzminsky: that might still be better than the learning curve of having to know how to add debounce components and wire them up...
11:25 AM archivist: when dealing with a new user there is an expectation of stepconf that is not realistic
11:25 AM cradek: when in that boat, you should fix your hardware instead
11:25 AM seb_kuzminsky: archivist: well, users always have unrealistic expectations ;-)
11:26 AM seb_kuzminsky: cradek: do you mean users should electrically debounce their limit switches?
11:26 AM archivist: hard to explain to them :)
11:26 AM seb_kuzminsky: archivist: always
11:26 AM cradek: seb_kuzminsky: more likely they should fix the grounding or noise problem
11:28 AM cradek: actual switch bounce isn't the thing people fix with the debounce component on their limit switches
11:28 AM jepler: or maybe the problem is you have a mechanical switch with bounce time on the order of 50ms https://softsolder.com/2012/07/13/contact-bounce-why-capacitors-dont-fix-it/
11:29 AM cradek: jepler: but even that is fine, because the trip (first high level) causes the machine to stop and wait for the human
11:30 AM seb_kuzminsky: on limit switches that's true, but on homing it can confuse the homing state machine
11:30 AM jepler: for homing, in the step where it reverses to move off the switch, the consequence of bouncing seems more likely to be severe
11:30 AM cradek: the fix people want to fix with debounce on limit switches is phantom occasional high levels, not any real switch bounce
11:30 AM jepler: sure
11:31 AM cradek: yes 50ms (!) of bounce on a home switch would screw everything up
11:31 AM jepler: "how s--ty is your home switch? [1 / 10 / 100 / 1000] microseconds of random bounce after activation
11:31 AM jepler: "
11:31 AM jepler: "[info icon] how will I find out this number? buy a $600 scope and get an EE major"
11:32 AM pcw_home: seb_kuzminsky: I wasn't thinking motion but rather the low level hardware driver (parport, hm2 etc)
11:32 AM seb_kuzminsky: pcw_home: i see, i misunderstood you
11:33 AM pcw_home: so just a input pin attribute
11:34 AM pcw_home: makes the GUI checkbox easier to implement...
11:40 AM seb_kuzminsky: sounds like a lot of duplicated code, to have debouncing in every input-pin driver
11:41 AM seb_kuzminsky: i guess we could put it in hallib
11:41 AM seb_kuzminsky: (if that's the right place to debounce)
11:41 AM jepler: yeah, there are a number of things that should be moved to hallib, and then their associated component becomes a thin wrapper on that
11:41 AM jepler: limit2/3, pid, debounce, ...
01:23 PM IchGucksLive: hi jepler are you on
01:23 PM IchGucksLive: i did see your video on the vismach or is it a single cut thru not implementet to vismach
01:24 PM IchGucksLive: for my education projekt this will give me 1year if not more at many schools to be ahead with CADcam to the real mashine
01:24 PM IchGucksLive: if a cad sim woudt run
01:24 PM IchGucksLive: on sim mashines of cause
01:25 PM IchGucksLive: the vismach runs perfect
01:25 PM IchGucksLive: but without stock cut
01:26 PM IchGucksLive: a implementation like insert on the toolsie and stock on the table side
01:26 PM IchGucksLive: so insert cuts to stock
01:26 PM IchGucksLive: that woudt be the perfect match
03:00 PM CaptHindsight: I need to add a temperature controller to LCNC....
03:01 PM CaptHindsight: it needs to control temp and ramp the temp up and down over time
03:01 PM CaptHindsight: I was thinking of using Classic Ladder and nested PID's
03:02 PM CaptHindsight: temp would need to go say from 30C to 150C with a ramp of one hour
03:02 PM CaptHindsight: then stay at 150C +/- 1 deg for 5 hours and then ramp down over 2 hours to room temp
03:03 PM CaptHindsight: any other suggestions?
03:12 PM jepler: It's safe to say I did not understand what IchGucksLive was asking about. it's true that a very long time ago I wrote a program intended to help preview the result of actually performing the cuts in a gcode part program, but it's long since bitrotted. https://emergent.unpythonic.net/01169521961
03:30 PM seb_kuzminsky: CaptHindsight: i'm doing something like that on my perpetually in-progress 3d printer, and i've thought of (cough) running linuxcnc on my heat treating oven
03:32 PM seb_kuzminsky: i read temperature with a thermistor connected to an ADC on a Teensy, connected to linuxcnc via USB (non-realtime, and the low update frequency here is fine)
03:32 PM seb_kuzminsky: i wrote a thermistor comp to covert the voltage to temperature
03:33 PM seb_kuzminsky: i use a 'comp' comparator component, comparing the thermistor temp to an analog-out pin from Motion (set with M67)
03:33 PM seb_kuzminsky: the comp component just turns on the heater if the temp is too low
03:33 PM seb_kuzminsky: it's pretty dumb, and it works pretty well
03:34 PM seb_kuzminsky: ramping is done in G-code, which is maybe not optimal for your use case
03:34 PM seb_kuzminsky: another option would be to use a siggen component to do the ramping, or to write a little program that emits the current temp setpoint on a pin, and net that to the comparator
03:39 PM CaptHindsight: seb_kuzminsky: I'm using a non-contact IR sensor (Pyrometer) with 4020ma output
03:39 PM CaptHindsight: 4-20ma
03:40 PM CaptHindsight: using your teensy code as well :)
03:41 PM CaptHindsight: have a 0.01% resistor on the input,
03:43 PM CaptHindsight: the temp ramps are before and after any G-code is run
03:44 PM CaptHindsight: the parts are so delicate that sudden temp changes can shatter them
03:51 PM CaptHindsight: I'm using similar pyrometers http://www.micro-epsilon.com/temperature-sensors/thermoMETER_CT_basic/#!#thermoMETER_CT_basic
03:56 PM andypugh: I am just setting up a VM with the Stretch LiveCD, and trying to compile LinuxCNC.
04:00 PM andypugh: With less that 100% success. Has anyone else seen this problem? https://paste.ubuntu.com/25285682/
04:00 PM jepler: these warnings are "normal" emc/usr_intf/halui.cc:91:23: warning: ignoring attributes on template argument ‘volatile real_t {aka volatile double}’ [-Wignored-attributes]
04:00 PM jepler: this is not: g++: internal compiler error: Killed (program cc1plus)
04:00 PM jepler: does it consistently repeat on the same file (emctask.cc in this case)?
04:01 PM jepler: how much memory did you allocate to the vm? is it at least 1GB RAM?
04:01 PM andypugh: Let me test
04:02 PM andypugh: yes, same file. Let me chack memory allocation
04:03 PM andypugh: Memory allocation was rather pitiful. I have 11GB of spare memory on the host, so 512MB was a bit mean for the VM
04:04 PM jepler: see if the error goes away with more RAM
04:05 PM jepler: seb_kuzminsky: do you know how much memory the stretch vms get on buildbot? I see it's not in environment-report
04:08 PM andypugh: More memory appears to have done the trick.
04:08 PM andypugh: Now to try to fix a parport driver without a parport, or the attached hardware :-)
04:09 PM jepler: andypugh: OK that's good to know
04:10 PM seb_kuzminsky: jepler: 2 gigs each
04:10 PM jepler: seb_kuzminsky: OK
04:10 PM seb_kuzminsky: i'll add it to environment-report
04:11 PM jepler: seb_kuzminsky: we'll clearly have to buy you an AMD Threadripper with 128GB RAM... then the buildbot will go real good
04:17 PM seb_kuzminsky: linuxcnc-build: force build --branch=2.7 1610.rip-stretch-rtpreempt-i386
04:17 PM linuxcnc-build: The build has been queued, I'll give a shout when it starts
04:17 PM linuxcnc-build: build #80 forced
04:17 PM linuxcnc-build: I'll give a shout when the build finishes
04:18 PM seb_kuzminsky: http://buildbot.linuxcnc.org/buildbot-admin/builders/1610.rip-stretch-rtpreempt-i386/builds/80/steps/environment-report/logs/stdio
04:23 PM jepler: neat thanks!
04:24 PM seb_kuzminsky: oh interesting, there's a second user of the teensy driver!
04:25 PM seb_kuzminsky: that's based on jepler's arduino driver and protocol, btw
04:50 PM linuxcnc-build: Hey! build 1610.rip-stretch-rtpreempt-i386 #80 is complete: Warnings [8warnings compile]
04:50 PM linuxcnc-build: Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1610.rip-stretch-rtpreempt-i386/builds/80
06:21 PM andypugh: I am looking at https://github.com/LinuxCNC/linuxcnc/issues/211
06:21 PM andypugh: But really not seeing any smoking gnu.
06:25 PM JT-Shopp is now known as JT-Shop
06:45 PM pcw_mesa: Still broken
06:51 PM andypugh: pcw_mesa: Did you pull 2.7 or master?
06:52 PM andypugh: (It’s a bug-fix, so it went in 2.7)
06:52 PM pcw_mesa: this is master
06:52 PM pcw_mesa: OK let me try 2.7
07:16 PM pcw_mesa: still broken on 2.7
07:21 PM andypugh: Broken the same way? ie, silently does nothing with no config string?
07:22 PM andypugh: I tested it, and got the same “you don’t actually have a card” error with both card types with and without a config string.
07:23 PM andypugh: So, I can believe that I have introduced a new bug if there is actually a card there to talk to, but wouldn’t expect to see the silently-failing behaviour.
07:25 PM pcw_mesa: Sorry, the 211 bug
07:26 PM andypugh: Ah, bother! SHould have been more explicit. I think I have fixed the 238 bug, but I am baffled by the 211 bug
07:27 PM pcw_mesa: Ill have to check the238 bug at home where I have LinuxCNC system with a parallel
07:27 PM andypugh: And I don’t know it I have anything to test the 211 with. Possibly this Renishaw read head?
07:28 PM andypugh: No real urgency, I am pterry confident in the fix.
07:28 PM pcw_mesa: Yeah the (211) register writing code looks right
07:28 PM pcw_mesa: maybe the check for need to write fails
07:30 PM pcw_mesa: perhaps easiest to debug 211 by looking at the actual register values
07:31 PM andypugh: I thought that was possible (I wondered if the “written” variable was 16-bit by mistake). I will keep looking.
07:33 PM pcw_mesa: The 12 reg is at 0x7400 and the 34 reg is at 0x7500
07:33 PM andypugh: Aye, raw-read might be the way to go
07:34 PM pcw_mesa: I vaguely remember discussing this with Jepler, let me poke at the regs a bit
07:34 PM andypugh: I will look for a 7i80 firmware with DPLL.