Back
[02:10:55] <seb_kuzminsky> is g10 a queue buster?
[02:57:42] <seb_kuzminsky> the t0 tests occasionally fail because they send deliberately invalid MDI commands, and interpreter errors cause mdi_execute_queue.clear(), so if the test gets unlucky and its mdi commands end up queued after a bad command, they get dropped
[02:57:47] <seb_kuzminsky> https://sourceforge.net/p/emc/bugs/429/
[02:57:52] <seb_kuzminsky> gnite
[03:00:07] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/mdi-drop 273a21f 06linuxcnc 10tests/t0/nonrandom/sim.ini 10tests/t0/random-with-t0/sim.ini 10tests/t0/random-without-t0/sim.ini tests: increase debugging * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=273a21f
[03:00:07] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/mdi-drop 20f5b46 06linuxcnc 10src/emc/usr_intf/shcom.cc shcom: log sending of mdi commands * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=20f5b46
[03:00:07] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/mdi-drop a23ee1a 06linuxcnc 10src/emc/task/emctaskmain.cc add task debug logging * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a23ee1a
[06:38:32] <jthornton> pcw_home, which one is weird?
[08:02:39] <memleak> Hi all, I came across this new C library called musl and it seems to be even smaller and less overhead than uclibc:
http://www.etalabs.net/compare_libcs.html
[08:03:43] <memleak> It'd be interesting to compare latency results between glibc and musl "all code in musl has been designed for realtime-quality robustness"
[08:07:19] <memleak> it even directly uses the linux syscalls, glibc doesn't even do that, now i'm really curious
[08:24:26] <pcw_home> In the FERROR section:
[08:24:28] <pcw_home> "The following polarity values determine how inputs are interpreted and how outputs are applied. They can usually be set via trial-and-error since there are only two possibilities. The LinuxCNC Servo Axis Calibration utility program (in the AXIS interface menu Machine/Calibration and in TkLinuxCNC it is under Setting/Calibration) can be used to set these and more interactively and verify...
[08:24:29] <pcw_home> ...their results so that the proper values can be put in the INI file with a minimum of trouble."
[08:24:31] <pcw_home> Not sure where that belongs but not under FERROR
[08:24:32] <pcw_home>
[08:26:34] <pcw_home> (probably it apples to input_scale and output scale)
[08:26:48] <jthornton> Ok thanks, I'll fix it
[08:38:56] <pcw_home> Maybe mousepad should be added to the suggested EDITOR values (for Debian)
[08:46:04] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/148360
[08:50:25] <andypugh> Interesting, when Celeron is considered slightly overkill for LinuxCNC.
[08:59:06] <skunkworks> seems to be trying so hard to put up with crap
[09:02:22] <jepler> #define YES (0)
[09:02:22] <jepler> #define MAYBE (1)
[09:02:22] <jepler> #define NO (2)
[09:04:12] <jepler> the docstrings also have some very terribly motivated examples
[09:04:17] <jepler> uint8_t CheckPassword(const char* password)
[09:04:17] <jepler> {
[09:04:17] <jepler> size_t length = utf8len(password);
[09:04:17] <jepler> return (length == utf8len("hunter2"));
[09:04:17] <jepler> }
[09:19:03] <jepler> anyway as for the mdi queue vs abort behavior, we should decide what we would like to have happen in that case
[09:19:17] <jepler> and then see if we can make that happen
[09:20:05] <jepler> my initial inclination is that it is right for an abort due to a gcode error to flush pending MDIs, just like it stops executing a part program
[09:20:29] <jepler> .. when you are using MDI as a poor-man's drip feed, and T1M6 fails, you do NOT want to go ahead with the next motions!
[09:22:31] <jepler> but the multiple queues (in 2.7, we have one in task, one in nml, and for all I know a third one in some UIs) and unreliable reception of task errors by multiple UIs mean this is not trivial to implement
[09:46:44] <pcw_home> Interesting about Rong Fu using Linuxcnc
[09:48:00] <ttiimm> RongFu post is from me :-)
[09:48:40] <pcw_home> I love that name
[09:49:22] <pcw_home> Like the "Good Luck" tire company
[09:53:16] <ttiimm> What would it take to allow Classic Ladder to be able to send motion commands to an axis for example durng a tool change that needs the Z axis to move? From what I know it cant be done this way now and you need to write comps , subroutines etc... would the whole code have to to be re written??
[10:07:05] <andypugh> ttiimm: I think that it would be a fair bit of work, CL communicates through the HAL layer and all the motion control is upstream of HAL.
[10:08:29] <skunkworks> but remap would work..
[10:08:52] <ttiimm> hi andy, this is actually sspeed33317 with the HAAS.
[10:08:53] <skunkworks> andy has done a cool demo demostrating it
[10:09:41] <ttiimm> I wish someone was close enough to me to come on over and help with me
[10:09:54] <pcw_home> It seems like it would simplify things if motion had offset inputs
[10:10:19] <ttiimm> anyone need a place to stay during a trip the states :-) Im in FLorida.
[10:11:10] <Tom_itx> seems alot of machines have toolchangers and that is one thing that hasn't been addressed that well
[10:12:18] <pcw_home> HAL --> offset inputs --> enable offsets --> TP
[10:12:25] <ttiimm> Seems like the ones that need axis movement have ben the most problematic
[10:25:54] <skunkworks> ttiimm:
https://www.youtube.com/watch?v=PfZwpjUs1xI
[10:26:46] <ttiimm> yep I have it on my computer already..
[10:35:48] <seb_kuzminsky> jepler: i think you're right that mdi-as-dripfeed means the use might sometimes want to have post-failure mdi commands dropped, and notification of the error reliably delivered to the source of the dripping
[10:36:25] <seb_kuzminsky> i think for now it's easy to have the test wait for completion after each questionable gcode, before emitting the introspection mcodes
[10:41:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/mdi-drop 339e1a6 06linuxcnc 10tests/t0/shared-test.sh tests: avoid mdi queueing after gcodes that can fail * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=339e1a6
[10:57:05] <pcw_home> skunkworks Not sure if its at all comparable but linuxcnc/axis on my 3 GHz C2D says about
[10:57:06] <pcw_home> 20% CPU usage with top (axis + rtapi_app) about 1/2 what mach4 is using (though I do have about 5% CPU for Ethernet interrupt at 3 KHz)
[11:01:15] <skunkworks> axis is using 95% right now for me..
[11:01:37] <skunkworks> but I also think top just shows 1 core usage..
[11:01:50] <skunkworks> because the computer is still responsive
[11:01:51] <pcw_home> yeah I think so
[11:03:02] <linuxcnc-build> build #1489 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1489 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:03:56] <seb_kuzminsky> top shows everything happening on the machine, on all cores
[11:04:00] <linuxcnc-build> build #1488 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1488 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:04:17] <seb_kuzminsky> well that didnt work
[11:05:07] <seb_kuzminsky> oh, haha, i added some new introspection and forgot to add it to the expected-output file
[11:05:10] <seb_kuzminsky> derp
[11:05:16] <linuxcnc-build> build #3328 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3328 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:06:03] <linuxcnc-build> build #1151 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1151 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:06:36] <linuxcnc-build> build #3329 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3329 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:07:26] <pcw_home> And linuxcnc seems to run fine on much slower machines
[11:07:28] <pcw_home> the N2820 that didnt do well with mach4 is about the same speed as a J1800
[11:07:30] <pcw_home> (which is about twice as fast as a D525)
[11:07:57] <linuxcnc-build> build #3330 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3330 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:10:05] <linuxcnc-build> build #2534 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2534 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:10:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/mdi-drop 305cd3d 06linuxcnc 10tests/t0/nonrandom/expected-gcode-output 10tests/t0/random-with-t0/expected-gcode-output 10tests/t0/random-without-t0/expected-gcode-output update expected output to match new test, derp derp * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=305cd3d
[11:11:08] <linuxcnc-build> build #3329 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3329 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:19:17] <skunkworks> http://imgur.com/90Oga4t
[11:23:48] <linuxcnc-build> build #3332 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3332 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:23:48] <linuxcnc-build> build #3339 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3339 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:24:21] <seb_kuzminsky> skunkworks: the "%CPU" value in top is the fraction of wall-clock time that the process was actually running on a cpu
[11:25:00] <seb_kuzminsky> if you have more than one cpu, you can get totals >100%
[11:25:35] <seb_kuzminsky> a multithreaded process can use more than 100% by itself
[11:25:42] <seb_kuzminsky> bbl
[12:03:32] <dgarr> pcw_home: a sim demo of a gui watchdog implementation (based on axis.ini, uses a py script for [DISPLAY]USER_COMMAND_FILE and a standard watchdog component):
http://www.panix.com/~dgarrett/stuff/gwatch.tar
[12:19:23] <pcw_home> Thats great
[12:19:24] <pcw_home> Maybe emcPT could try it with his GUI hang issue
[12:19:26] <pcw_home> with a watchdog bite setting motion.enable false
[12:46:12] <pcw_home> I'm not sure if his issue is that KB and mouse went away because of USB noise issues
[12:46:14] <pcw_home> or some GUI hang
[12:46:15] <pcw_home> A GUI hang during jogging would be very noticeable but a
[12:46:17] <pcw_home> a KB/mouse hang from servo /spindle noise might not be noticed
[12:46:18] <pcw_home> during operation since theres no user intervention. so I still suspect noise
[15:42:42] <jepler> seb_kuzminsky: what's branch mdi-drop do to the test duration?
[18:11:58] <seb_kuzminsky> jepler: it only waits after sending the G10 and G43 commands, all the M-codes are still queued
[18:12:07] <seb_kuzminsky> the time impact should be minimal, but i haven't measured it
[18:22:10] <andypugh> seb_kuzminsky: With the recent fixes are we “go” for the carousel comp + demo? If so, do I need to do something, or will you merge the feature branch?
[18:35:42] <seb_kuzminsky> andypugh: jepler fixed both the issues that your branch uncovered, right? if it runs clean now please merge it into 2.7
[18:35:55] <seb_kuzminsky> or i can do it if you prefer
[18:36:44] <andypugh> I think it is probably better if you do it, I would have to Google for the procedure
[20:29:32] <seb_kuzminsky> ok, you test & i'll merge
[20:46:56] <arrowbook> does the stepgen.c only drive the stepper motors? if so, then where's the servo motors controlled?
[21:21:39] <Tom_itx> pwmgen
[21:22:41] <cradek> wellll
[21:23:00] <cradek> linuxcnc outputs requested positions every servo cycle
[21:23:11] <cradek> you can track that with motors in lots of ways
[21:23:45] <cradek> a servo machine most often uses pid and a velocity-mode output of some kind
[21:24:15] <cradek> some servo amps take digital pwm, some take analog voltage specifying velocity
[21:24:21] <cradek> still others do other things
[21:24:46] <cradek> you can run all of them with linuxcnc by using appropriate hal building blocks appropriately :-)
[21:33:35] <cradek> and it's a mistake to think that software stepgen is always involved in driving stepper motors
[21:33:43] <cradek> there is huge flexibility and variation
[21:37:09] <arrowbook> thankyou, do you mean stepgen.c can also drive servo motors?
[21:37:44] <cradek> what is your real question? are you trying to build a machine or solve a problem or figure out what hardware to buy or what?
[21:39:55] <arrowbook> i want to make my 4 axes machine to move by transforming the offset to pulse
[21:41:05] <arrowbook> and i want to know the internal mechnism