Back
[05:49:40] <jthornton> all of my plasma files do a G92 X0 Y0 at the start of the program. I always get an out of bounds error when I press run. Is Axis generating this or the interpreter? It seems that LinuxCNC should know my current XY location and not give that error.
[05:49:45] <jthornton> just thinking out loud
[08:50:22] <seb_kuzminsky> jthornton: can you reproduce it in sim?
[08:50:50] <seb_kuzminsky> anyone: do you know of any reason why i shouldnt release 2.7.0? any show stoppers?
[08:51:28] <cradek> people who were paying attention yesterday: does it turn out that locking rotaries work as expected?
[08:57:27] <etv> I had a + - 10 closed loop and everything worked ok
[08:57:44] <JT-Shop> seb let me see here in a bit if I can
[08:57:45] <etv> +-10V analog with closed loop
[08:58:41] <etv> after change servo and set step/dir i have situation to axis.unlock signal is off before end of motion
[08:59:52] <etv> Tomorrow I will try some changes in this configuration and we will notify you about changes
[09:03:56] <etv> currently ferror and min_ferror is too large in the ini files (for the test), maybe it's a problem?
[09:49:30] <jepler> cradek: is there a locking rotary sample configuration file?
[09:50:25] <cradek> axis_9axis.ini:LOCKING_INDEXER = 0
[09:50:51] <cradek> if you turn it on here I think there's hal sim setup that uses a delay for the loopback
[09:55:50] <jepler> yes
[09:56:54] <jepler> it looks OK to me in halscope. B-unlock goes FALSE when Bpos (<= axis.4.motor-pos-cmd) reaches the endpoint of the move
[09:57:48] <cradek> and it waits for the loopback to change state before and after the move?
[09:58:15] <jepler> well I'm just doing MDI so I don't know for certain. let me check that.
[09:58:48] <cradek> please also check that homing unlocks
[10:00:39] <jepler> ok, next test. yes, a G0 Z move does not start until after B-is-unlocked becomes FALSE
[10:01:30] <jepler> third test. yes, homing unlocks and waits for is-unlocked
[10:01:44] <cradek> yay
[10:01:49] <cradek> sounds right
[10:02:04] <cradek> thanks for doing that
[10:02:06] <jepler> fourth test. I set ferror and min-ferror very large, and disconnect axis.4.motor-pos-fb entirely. unlock and is-unlock continue to behave the same.
[10:02:50] <jepler> .. this gives the observed behavior that the lock is engaging again even though the feedback position has not reached the commanded position.
[10:03:19] <jepler> so I remain confident that the locking rotary feature is working as designed, and that etv's problem will be resolved when the following error is resolved.
[10:03:36] <cradek> I agree with you
[10:06:40] <seb_kuzminsky> thanks guys
[10:07:52] <cradek> seb_kuzminsky: I see nothing but clear skies
[10:09:51] <jepler> blue skies smiling at you?
[10:13:37] <etv> I have another big objections to the work of indexing rotary axis!
[10:13:48] <etv> Once you start axis and if something goes wrong axis.n.unlock remains active until the shutdown LCNC applications
[10:14:17] <cradek> what do you mean goes wrong?
[10:15:49] <etv> axis.n.unlock signal should be reset with the help of F1 or F2 in AXIS
[10:16:20] <jepler> cradek: command a lengthy move of a locking rotary, and hit estop during the move
[10:16:42] <cradek> I think it should stop the move AND stay unlocked
[10:16:46] <jepler> after returning to machine on, axis.is-unlocked and axis.unlock remain TRUE
[10:17:01] <cradek> I don't know exactly how you should recover
[10:17:05] <etv> yes
[10:17:07] <cradek> you sure can't just command a lock wherever you are
[10:17:17] <etv> remain true
[10:17:28] <jepler> in this state you can command e.g., G0X1
[10:17:36] <cradek> does homing the axis again fix it?
[10:17:45] <etv> no
[10:17:51] <jepler> yes
[10:18:13] <jepler> I found two ways to return the B axis to locked state: Another G0 B- move, or homing.
[10:18:29] <cradek> those both seem like fine ways to recover
[10:18:57] <cradek> if there is a bug, it's this: jepler> in this state you can command e.g., G0X1
[10:19:51] <jepler> abort and machine off all behave similarly to estop: they leave the axis unlocked
[10:19:57] <etv> you should be using F1 or F2 to state axis.n.unlock reset
[10:20:12] <cradek> no
[10:20:13] <jepler> etv: I disagree.
[10:20:21] <cradek> you should never lock unless you are in a known commanded position
[10:20:22] <jepler> Suppose a locking rotary can only lock at multiples of 15 degrees
[10:20:34] <jepler> but you press the estop button when it is at 10 degrees
[10:20:48] <cradek> those are immediately after homing OR immediately after a move succeeds
[10:21:51] <jepler> anyway, two recovery procedures: MDI G0 B- or re-home axis B (depending on the user interface, may have to say yes when asked whether to home an axis that was already homed)
[10:23:26] <jepler> another reason not to lock on estop: engaging the lock usually means making something move. You don't want something to move when you use the estop button!
[10:23:58] <etv> My plc monitoring signal axis.n.unlock and activates the hydraulics
[10:24:36] <etv> Hydraulics remains constantly active, and that I wanted to avoid
[10:25:07] <cradek> if you want to do something special (like apply a brake) in estop or machine-off state, do that
[10:25:41] <cradek> in those states, maybe you ignore axis.N.unlock and do something more approriate
[10:25:55] <jepler> yes you can make those choices in your hal configuration and plc
[10:25:58] <pcw_home> if its safe to lock at any position/velocity...
[10:26:04] <jepler> we cannot tell you what is appropriate or safe
[10:26:06] <cradek> many machines have brakes that you might want to apply in estop
[10:26:26] <etv> I'd be happier if the signal axis.n.unlock reset to F1 or F2
[10:26:46] <pcw_home> lots of others migh be unhappy
[10:26:53] <cradek> I think that would be objectively worse behavior
[10:27:03] <cradek> so instead, you just need to adapt your hal
[10:27:19] <jepler> it would damage many types of locking rotary tables to do that
[10:27:29] <jepler> bbl
[10:27:31] <archivist> I think rotaries have manuals which state how they should be driven
[10:29:09] <etv> absolutely understand how it works
[10:29:58] <etv> I have hydraulics and pressure switch
[10:30:17] <etv> Simply can not be simpler
[10:31:16] <msantana> cradek: currently the Debian distro has these preemptive kernels via backports:
https://packages.debian.org/search?suite=jessie-backports&searchon=names&keywords=linux-image%20rt and these in testing version:
https://packages.debian.org/search?suite=stretch&searchon=names&keywords=linux-image%20rt
[10:31:58] <msantana> I'm doing some tests with the kernel from testing
[10:33:19] <etv> When activated F1 everything has to stop axis.n.unlock must be reset
[10:33:29] <etv> PLEASE CHECK
[10:35:00] <msantana> cradek: Do you have any objections or recommendations regarding the version 4.1 of preemptive linux kernel?
[10:38:51] <pcw_home> etv: imagine a indexed locked rotary with a pin, this would cause damage if locked at estop
[10:39:15] <etv> ok
[10:40:03] <pcw_home> if you want it locked after a Estop you need to implemet this in your hal file (with a and or or component perhaps)
[10:40:10] <etv> my case is different
[10:41:00] <pcw_home> This is what HAL is for, intefaceing LinuxCNC to your specific hardware
[10:41:08] <etv> I'll try, thanks
[10:42:31] <etv> perhaps to learn programming and change lcnc :)
[10:43:22] <pcw_home> you certaainly can but its better to do machin specific modification in HAL (thats what its there for)
[10:43:30] <archivist> it can be unwise to think your case is the general use case
[10:44:15] <etv> you're absolutely right
[10:44:52] <pcw_home> I think in your case, what you want is done very simply in HAL
[10:47:09] <etv> I used axis.n.unlock to start my logic
[10:48:22] <etv> start hydraulics and wait for pressure switch => axis.n.is-unlock >> start move
[10:50:40] <etv> my A axis has no index pin and freely moving full circle
[10:51:23] <etv> hydraulics only release clamping
[11:05:42] <pcw_home> sounds like you just need to factor in axis.0.amp-enable-out or some such so your rotary locks on faults
[11:10:12] <etv> a good proposal
[11:34:28] <pcw_home> hmm, uspace done not like flaky internet connections
[11:35:22] <pcw_home> does not like
[11:35:48] <pcw_home> ntp troubles perhaps
[11:39:01] <jepler> that's troubling
[11:39:16] <jepler> what are you seeing?
[11:42:13] <pcw_home> look like steps in the timebase frequency
[11:43:36] <pcw_home> my WIFI is being flaky today and I noticed my always running hm2_eth linuxcnc instance got a following error
[11:44:12] <jepler> uspace uses CLOCK_MONOTONIC for timing things. The documentation says that this is affected by non-discontinuous changes to the system clock made by ntp
[11:44:27] <pcw_home> I can duplicate it by turning WIFI off for some time and then on again
[11:46:01] <pcw_home> my DPLL read ahead time is 50 usec but theres a larger baseline shift than 50 usec, so the read-ahead fails and the sample is of by ~ a thread time
[11:47:48] <pcw_home> i can see slow adjustments that NTP makes (small frequency offset for a minute or two) but there are fairly large jumps
[11:49:16] <jepler> hm my hm2_eth setup is turned off
[11:49:56] <pcw_home> I can adjust the DPLL to follow fairly quick changes (at the cost of a little more sample jitter) but
[11:49:58] <pcw_home> step changes (if they are steps) are a problem, I'll try and capture a HALScope trace
[11:52:18] <jepler> they are not supposed to be steps
[11:52:27] <jepler> but whether they are not steps compared to 50us, I don't know
[11:53:58] <jepler> I'll see what I can determine on my end tonight
[11:54:55] <pcw_home> Ack not faste enough reaction to catch a trace need to trigger on FE...
[12:31:22] <pcw_home> dpll tracking a relatively fast ntp offset:
[12:31:24] <pcw_home> http://ibin.co/2EHcRwAGozcR
[12:32:24] <pcw_home> or rather failing to track :-(
[12:50:55] <pcw_home> OK easily fixed, just dont use such a long a DPLL time constant
[13:03:08] <pcw_home> this does suggest that the default value should be lower
[13:15:02] <jepler> ntp can make several kinds of adjustments.
[13:16:02] <jepler> It can make a large step in the current time (settimeofday syscall), it can arrange for a small adjustment to be applied over time (adjtime or adjtimex syscall), or arrange to apply a small 'trim' to the clock source (adjtimex)
[13:16:25] <jepler> I think that the second two kinds of adjustments are being seen in the timestamps that come from CLOCK_MONOTONIC
[13:20:30] <PCW> yeah, just a bit too fast to track with the default DPLL settings
[13:21:15] <PCW> setting the DPLL time const pin to 500 fixed the FE issue
[13:22:27] <PCW> thats probably too low (~20 ms) but I have not had a chance to try other values
[13:23:44] <jepler> trying to capture the effect of adjtime on CLOCK_MONOTONIC timekeeping: /shared/home/jepler/scope-adjtime.png
[13:24:10] <jepler> I have a stepgen commanded 10000st/s in velocity mode, and then I do a ddt on the feedback position
[13:28:41] <PCW> on my plot the slew is gradual (no big phase jump) but a 50 uses adjustment happens in about 160 ms (and the default 1-2 second DPLL time constant means the DPLL cant track it
[13:29:35] <PCW> so speeding up the DPLL is an easy fix (setting the time const pin)
[13:31:57] <PCW> so the driver default should probably be lowered
[13:35:12] <PCW> better the default is noisy and fast than the sample miss a whole servo thread time if the Internet connection is flaky
[13:35:25] <jepler> I agree
[13:36:28] <jepler> hm I haven't reproduced my earlier plot yet
[13:36:59] <PCW> probably never notice except for a flaky WIFI connection
[13:39:12] <jepler> ah there
[13:50:49] <jepler> http://emergent.unpythonic.net/files/sandbox/scope-adjtime2.png
[13:51:27] <jepler> hostmot2 position-fb -> ddt -> lowpass, while changing linux clock parameters with adjtime
[13:51:33] <jepler> first a positive offset is applied, then a negative one
[13:51:51] <jepler> +-5/10000 = +-500ppm
[14:19:01] <PCW> look like the same time constant as my plot (about 150 ms)
[14:20:08] <PCW> (unless thats your lowpass)
[14:28:00] <jepler> that's my lowpass
[14:28:25] <jepler> otherwise the noise swamps the signal
[14:39:57] <jepler> I wonder what a "Intel Pentium J2900 2.14GHz" is
[14:41:01] <jepler> woot has an interesting small form factor PC today, $240, 4GB, 500GB, 1 ethernet + wifi + several USB, vga + displayport
[14:42:55] <PCW> the J2900 is the 2.14 --> 2.4 GHz version of the J1900 (4 core Baytrail)
[14:44:02] <jepler> I wonder how its build speed is compared to Core2 E8500 @ 3.16GHz
[14:44:14] <PCW> should be decent for LinuxCNC (the J1800/1900 are)
[14:44:19] <jepler> the latter having only 2 threads
[14:44:40] <PCW> probably similar if all cores are working
[14:44:55] <ikcalB> (sry, vim c'n'p): hey guys. has anyone encountered theses behaviors? (i cannot find open bug reports about those):
[14:45:08] <ikcalB> 1. halshow does not parse hierarchy for Signal names. "Drive.A.PosSet" is going to be 'Signals --> Drive --> Drive.A.PosSet' instead of 'Signals --> Drive --> A --> PosSet' (what works perfectly for
[14:45:15] <ikcalB> 2. when aliasing a pin, the original name is not displayed anymore - regardless of haltcl / halshow (though referring to the orig name still works)
[14:48:31] <jepler> "halcmd show alias" shows information about pin and parameter aliases.
[14:49:13] <jepler> the halshow GUI is unmaintained and so filing bugs or feature requests about it is unlikely to lead to it being improved. We would be happy to see someone begin maintaining it, however.
[19:04:06] <jepler> pcw_home: I have not found a case where messing with NTP or related syscalls can change the CLOCK_MONOTONIC rate by more than +-500ppm. but that means that if it goes from the maximum positive adjustment to the maximum negative adjustment, the rate of CLOCK_MONOTONIC can change by 1000ppm = .1%
[19:06:45] <jepler> .. but that is just 1us per ms, if it is truly applied equally
[19:07:31] <jepler> so I feel like it is not explaining what is going on
[19:08:12] <jepler> pcw_home: it would be interesting if you could confirm that if you 1) make sure ntpd is *NOT* running and 2) disrupt and then reestablish the wifi connection
[19:08:18] <jepler> .. that the problem does not occur
[19:08:47] <jepler> since the original hypothesis is that it's related to ntp, this could disprove the hypothesis
[19:33:30] <jepler> I should mention, I'm testing on
[19:33:30] <jepler> Linux rat 3.14-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian 3.14.15-2~bpo70+1.1 (2014-10-30) x86_64 GNU/Linux
[19:33:45] <jepler> this might be different from kernel to kernel though I kind of doubt they're changing timekeeping algorithms much these days
[20:57:02] <PCW> I can try disabling ntp but 1 us/ms is not trackable with the default DPLL settings
[20:57:03] <PCW> so if the phase can shift that fast the DPLL time constant must be shorter
[21:05:06] <jepler> OK, I see what you mean now.
[21:07:04] <jepler> either we need to advise to disable network timekeeping, or set the default pll constant to accomodate step changes of 1000ppm in the clock linuxcnc uses.
[21:07:19] <PCW> No a big deal
[21:07:21] <PCW> setp hm2_somecard.dpll.time-const 500
[21:07:22] <PCW> fixes it
[21:08:30] <jepler> src/hal/drivers/mesa-hostmot2/dpll.c: *hm2->dpll.pins->time_const = 0xA000;
[21:08:35] <jepler> should I change this constant to 500?
[21:08:39] <PCW> just surprised me since a random FE is bad news
[21:08:44] <jepler> yeah
[21:09:27] <PCW> I can try and find a better value, 500 is the first and last I tried
[21:09:32] <jepler> OK
[21:10:22] <jepler> if you like, I can give you a commandline program that will let you bang the adjtime correction factor around
[21:10:37] <jepler> http://emergent.unpythonic.net/files/sandbox/futime.c
[21:11:08] <jepler> compile it, make sure ntpd is stopped, and run ./futime 10000 to make linux think it's 10000us slow, or -10000 to make linux think it's 10000us fast
[21:11:59] <PCW> that would be a bit easier than disabling/re-enabling internet access and hoping the PCs clock had drifted enough...
[21:12:13] <jepler> in my testing, that consistently subtracts or adds 500ppm compared to the normal rate of the clock, using this program which compares CLOCK_MONOTONIC's rate with a local ntp server's rate (hardcoded as an IP address)
http://emergent.unpythonic.net/files/sandbox/ntpdd.c
[21:13:07] <jepler> oh and ./futime 0 to make linux think it's clock is dead on
[21:13:54] <jepler> "its clock"
[21:14:09] <jepler> time to tidy up the kitchen. bbl.
[21:14:25] <jepler> oh and futime needs root (sudo) to work
[21:14:39] <PCW> if you look at the DPLL phase error you can see that fairly fast adjustments are made and then long term small frequency offsets are used
[21:15:58] <PCW> Thanks for looking into this
[21:15:59] <PCW> bbl
