Back
[02:20:58] <NTU> 25 hours later and im almost ready to try out UEFI + linuxcnc + RTAI
[02:22:17] <NTU> getting linux to boot without any CSM / legacy Oprom was incredibly difficult
[02:46:24] <NTU> jepler, proposed-master is looking good :)
[02:50:03] <NTU> dpaste.com/11CJF3X
[02:50:30] <NTU> all is well, im going to let latency-test run over night, cheers!
[08:32:16] <tjtr33> hello, i want to experiment with usrmot. is it doomed to be retired or does it have life in the future of linuxcnc?
[08:44:11] <jepler> tjtr33: in the release notes for 2.6.0~pre1 it says "removed usrmot (buggy & unused)"
[08:44:21] <jepler> at best it has been unmaintained for a very long time
[08:45:30] <micges> tjtr33: at least from 2008
[08:45:37] <jepler> to be honest I don't even know what usrmot is
[08:46:16] <jepler> oh hey I sort of knew what it was when I wrote the message on commit 30dd950
[08:47:42] <jepler> .. so is src/emc/motion/usrmotintf* dead code too?
[08:49:10] <micges> no, it's user level of emcmot
[08:49:19] <jepler> ok, two things with the same name
[08:50:08] <micges> iirc usrmot was direct interface to using and testing emcmot, without any gui
[08:52:05] <jepler> if you wanted to do that today, you should use a simple python program as your DISPLAY, or linuxcncrsh
[08:52:15] <jepler> we do this in a number of tests
[08:52:16] <jepler> halui-jogging/halui.ini:DISPLAY = ./test-ui.py
[08:52:21] <jepler> linuxcncrsh/linuxcncrsh-test.ini:DISPLAY = linuxcncrsh
[08:52:28] <jepler> ^^ inifiles in the testsuite
[09:14:15] <tjtr33> i looked at the linuxcncrsh file set, and the halui-jogging. i dont see either doing my dream.
[09:14:23] <tjtr33> in 2006 Dave Engvall wrote a few tiny c programs, that piped data into usrmot.
[09:14:33] <tjtr33> The idea was to implement EDM, where the correct position _now_ for the tool tip is the present analog voltage of the process.
[09:14:42] <tjtr33> The code set new destinations for the tool tip with every sample of the process's analog input.
[09:14:49] <tjtr33> Each of the new commands was preceeded with an abort.
[09:14:51] <tjtr33> I dont see the examples for linuxcncrsh or halui-jogging allowing such action. am i missing soemthing in the examples?
[09:15:46] <jepler> tjtr33: those are in tests/ in the source tree
[09:15:56] <tjtr33> thats where i read them yes
[09:16:03] <jepler> there aren't any exmaples in configs/
[09:16:13] <jepler> oh wait you said more things and I didn't bother to read them
[09:17:57] <jepler> my first impulse is to say: you could just command the motor positions in hal and not use task at all
[09:18:42] <jepler> in that world, your uesrspace part would be a hal component with X, Y, Z outputs. You'd hook X to your positioning part (e.g., pid input or stepgen position input)
[09:20:17] <jepler> stepgen has an internal trapezoidal motion planner, so you can enforce velocity and acceleration limits
[09:20:26] <jepler> but X and Y would not move in coordinated fashion
[09:21:20] <tjtr33> yeah, done that, hal gap control to stepgen, but thought usrmot would be cleaner, more versatile. I posted videos even. ok, thx
[09:21:21] <jepler> anyway, in the linuxcnc module for python there is abort() which is like hitting escape in a user interface, and you can plan a move to a given location with mdi("G0 ...")
[09:21:42] <tjtr33> oh coordination is done in hal to do 'orbiting' about the tool axis
[09:21:48] <jepler> if you want to bring usrmot back to life, nobody is particularly against it
[09:22:04] <jepler> probably it's broken for some simple / stupid reason that is easy to fix
[09:22:43] <tjtr33> oh cool, will look into abort(). i was avoiding the abort by using the smallest unit of motion,
[09:23:02] <tjtr33> will look into the usrmot code, maybe i can understand it
[09:23:04] <tjtr33> thx again
[09:23:52] <jepler> you can start with: git revert 30dd950
[09:23:59] <jepler> that undoes the commit that deleted usrmot
[09:24:24] <tjtr33> using 1 micron moves avoids accel decel :)
[09:24:37] <jepler> it still builds
[09:25:00] <jepler> probably you would want to configure linuxcnc to run in userspace: ./configure --with-realtime=uspace
[09:25:13] <jepler> so that you can run the debugger on task, and not have to reboot after each time it crashes
[09:26:02] <jepler> if you get it to work again, and add a basic test in tests/ that uses usrmot (so we know if it becomes buggy and just crashes task all the time) I would be happy to see usrmot back in the master branch of linxcnc
[09:26:18] <jepler> (er, I guess task is userspace anyway so you can use whatever realtime you want)
[09:27:25] <tjtr33> i have old code rips with usrmot. i'll look there first, then plunge into the rest.
[09:27:26] <tjtr33> i'll try
[09:28:24] <tjtr33> (tomp copies irc session to text file for ref :)
[09:28:41] <jepler> writing a test of usrmot that works back at that old ref would be useful
[09:29:07] <jepler> with such a test, it is possible to have git automatically determine at what change the test started to fail
[09:29:32] <tjtr33> Dave said the 'v' ( set vel) cmd didnt work back in 2006
[09:30:03] <tjtr33> i only have my laptop here in taipei, no ports, no mesa, no machine tool
[09:30:44] <tjtr33> but return in 1 week
[09:30:48] <tjtr33> thxd very much
[09:30:54] <jepler> good luck
[09:31:48] <jepler> if you do write a test that passes with some old linuxcnc version please let us see it
[09:32:02] <jepler> with that test I can at least help with the step of finding out where along the way usrmot got broken
[09:32:19] <jepler> something that can be automatically run like the stuff in tests/
[09:33:43] <jepler> should be possible while trapped in a hotel room with nothing but a linux laptop
[09:34:01] <tjtr33> http://imagebin.ca/v/1YjKAUlFdE6d
[09:34:24] <tjtr33> hehe ok
[09:35:02] <jepler> so which command can you successfully send in 2.5.2?
[09:35:11] <jepler> can you enter 1 1 1 and have it move?
[09:35:17] <tjtr33> /?
[09:35:28] <tjtr33> ^^^ thats the cmd i can give
[09:35:33] <jepler> any others?
[09:35:38] <tjtr33> gives me the list of commands
[09:36:01] <tjtr33> i'll get a list of what i can do
[09:36:42] <tjtr33> iirc in hongkong airport it just complained, but will test and report
[09:37:08] <tjtr33> setting up session now
[09:38:43] <tjtr33> oh, does this seem reasonable? i use a terminal window , issure linuxcnc &, then cd to some ini dir , then issue /usr/bin/usrmot -ini /path/to/someinifile.ini
[09:39:06] <tjtr33> i did that so i could use a stp cfg ( no hdwr really needed, and had axis to display position
[09:40:14] <jepler> the comments in the sample configuration files seemed to imply it was used as a DISPLAY =
[09:40:33] <jepler> but .. I dunno, I don't recall ever successfully using the usrmot program
[09:43:58] <tjtr33> ah other cmds are working quit sjhow config show flags
[09:44:35] <tjtr33> and i cant move with show flags saying i'm on limit ( silly choice of .ini file )
[09:44:52] <tjtr33> will choose un-limited stepper cfg or make one
[09:48:00] <jepler> motion> coord
[09:48:00] <jepler> motion> 0 0 .01
[09:48:00] <jepler> Internal error: unhandled motion type 0
[09:48:00] <jepler> rtapi_app: caught signal 11 - dumping core
[09:48:00] <jepler> USRMOT: ERROR: command timeout
[09:48:03] <jepler> error: Internal error: unhandled motion type 0
[09:48:05] <jepler> error: rtapi_app: caught signal 11 - dumping core
[09:48:12] <jepler> so here's what happens when I try to command a move via usrmot
[09:51:23] <tjtr33> i got err too, told it to go where it was, (less risky), diff error USRMOT: ERROR: command timeout error: Internal error: unhandled motion type 0
[09:51:48] <tjtr33> so i may need to specify the motion type, i have not looked at src yet
[09:54:32] <tjtr33> tried this: motion> a -->USRMOT: ERROR: command timeout ok, look at code before proceeding, thats not a complicated cmd
[09:55:51] <tjtr33> i didnt dump core, but got warned that reboot maybe necc
[10:05:49] <tjtr33> hey sorry if it messed with your system. dont poke at it, i'll play here
[10:05:53] <tjtr33> thx bye
[10:10:36] <jepler> http://emergent.unpythonic.net/files/sandbox/0001-Fill-out-new-required-fields-in-emcmot_command_t.patch
[10:10:50] <jepler> reverting the removal of usrmot, plus this, lets me actually command a move
[10:11:35] <jepler> but the new values need to come from somewhere in usrmot, not just be hard-coded
[10:12:51] <jepler> (drat, missed him)
[10:13:40] <jepler> what protects the shared memory area from being written by usrmot and task at the same time?
[10:14:00] <jepler> I guess task mostly won't write unless you send it nml commands
[10:33:50] <pcw_home> Gaah getting too crotchety to answer forum questions
[10:35:53] <tjtr33> jepler,
http://imagebin.ca/v/1Yjch94ZZiLP no errs , but no motion
[10:36:19] <tjtr33> gnite
[11:09:04] <NTU> 28380 on servo thread, 14598 on base thread with new RTAI scheduler, no isolcpus set (all 4 cores available to system)
[11:43:16] <jepler> pcw_home: I know how you feel!
[11:43:57] * jepler realizes that without looking he has no idea what time it was where tj is
[11:44:03] <jepler> I'll assume it was late
[12:32:44] <jepler> new board is talking to 7i43 over spi again
[12:32:53] <jepler> .. yay
[12:33:36] <jepler> now to find appropriate power for the 7i90. the usb jack on the 7i43 is too convenient.
[12:38:43] <NTU> so whats the status on SPI? it works now?
[12:40:10] <NTU> looks like i need to bump RTAI again...
http://git.xenomai.org/ipipe.git/log/?h=ipipe-3.14
[12:41:22] <jepler> 'ASEM09I7'
[12:41:31] <jepler> NTU: spi still has latencies I'd like to be rid of
[12:42:06] <NTU> ok.
[12:42:06] <jepler> NTU: but now I have my second version level converter board, replaced the 2mm headers on the odroid, and have a 7i90 instead of a 7i43 for testing
[12:42:45] <jepler> that's what's new today
[12:43:17] <NTU> also does ps -aF show what core the real-time latency thread is running on and if so, which one?
[12:43:41] <NTU> latency-test, halrun and pyvcp show up
[12:44:14] <jepler> NTU: on rtai systems, the linuxcnc realtime stuff is not a linux userspace process, so as far as I know ps doesn't list it
[12:44:26] <NTU> oh..
[12:44:40] <jepler> NTU: there's a file in /proc which lists information about realtime stuff, you can see rtai's claim about what CPU is in use there
[12:44:44] <jepler> I forget the path to that file
[12:44:50] <Tom_itx> jepler is the 7i90 still parport interface?
[12:45:08] <Tom_itx> more io than the 7i43?
[12:46:02] <NTU> ok thanks jepler :)
[12:46:10] <jepler> Tom_itx: 7i90 supports several different interfaces depending on the fpga firmware
[12:46:18] <Tom_itx> mmm, parport, spi or rs422
[12:46:20] <jepler> Tom_itx: epp, spi, and two serial protocols (lbp and lbp16)
[12:46:59] <Tom_itx> spi would be for your arm interface?
[12:47:05] <jepler> Tom_itx: right
[12:47:13] <Tom_itx> makes more sense now
[12:47:35] <jepler> I built a custom 7i43 firmware that worked over spi, but nobody would want to use it for real
[12:48:01] <jepler> in part because it had to steal a pin from one of the two I/O connectors (a "GCLK" special purpose pin)
[12:48:14] <Tom_itx> does the 7i90 support sserial?
[12:48:45] <Tom_itx> i'd imagine you could mod the bit file like i did on the 7i43
[12:48:55] <jepler> you mean sserial daughtercards? With the right firmware I'm sure it does
[12:48:58] <Tom_itx> yes
[12:49:02] <jepler> I don't know what firmwares peter offers prebuilt
[12:49:06] <Tom_itx> i just read...
[12:49:32] <Tom_itx> Firmware modules are provided for hardware step generation, quadrature encoder counting, PWM generation, digital I/O, Smart Serial remote I/O, BISS, SSI, SPI, UART interfaces and more.
[12:50:57] <jepler> the firmware that the device shipped with (he preprogrammed it with the firmware that communicates over spi) looks like an "SV4_ST8" -- 4 encoders, 4 pwmgens, 8 stepgens
[12:51:01] <Tom_itx> more io but cheaper than the 7i43
[12:51:39] <jepler> for all I know he prices the 7i43s high enough to discourage anyone from purchasing them now
[12:52:09] <Tom_itx> i think it's the same as when i got mine... just before the 5i25 was released
[12:52:23] <jepler> I hate it when that happens.
[12:52:26] <Tom_itx> heh
[12:53:59] <Tom_itx> i think it technically was out but i was new and it was new and drivers were scarce
[12:54:11] <pcw_home> The 7I90 supports almost all 72 I/0 configs (the 36 stepgen config wont fit for example))
[12:55:07] <Tom_itx> is it a smaller fpga?
[12:55:38] <pcw_home> 7I90 has a bigger FPGA than 7I43
[12:55:51] <pcw_home> (but newer and cheaper)
[12:55:53] <Tom_itx> what makes it cheaper?
[12:55:56] <Tom_itx> newer..
[12:56:05] <pcw_home> smaller geometry
[12:57:05] <pcw_home> just fixed the resolver interface so it will work in the 7I90/7I80 etc
[12:57:27] <jepler> hm something's weird
[12:58:00] <jepler> my stepgen has velocity-cmd 1 but I get velocity-fb of about .75
[12:58:16] <jepler> maybe I'm hitting a step rate limit
[12:59:22] <jepler> aha
[13:02:39] <pcw_home> my test hm2-pidstepper config is using 20 IPS rapids but had to
[13:02:40] <pcw_home> set 1 usec steptime and stepspace to get there (with reasonable scales)
[13:03:17] <jepler> so I am running one stepgen in velocity mode and doing ddt of position
[13:03:44] <jepler> I believe that if I encounter a "true" latency it will cause the ddt-of-position to spike
[13:03:52] <jepler> so I'll just let that run a bit
[13:04:43] <jepler> and of course just after explaining those plans .. it did!
[13:04:52] <jepler> it also logged some of these:
[13:04:52] <jepler> hm2/hm2_7i90.0: (hal/drivers/mesa-hostmot2/encoder.c:938) uh-oh, encoder vel is broken when slow
[13:04:56] <jepler> hm2/hm2_7i90.0: please email a bug report to the linuxcnc-devel list!
[13:04:58] <jepler> hm2/hm2_7i90.0: dS_counts=-1, dT_clocks=0
[13:05:01] <jepler> hm2/hm2_7i90.0: prev_update_dS_counts=-1, prev_update_dT_clocks=0
[13:06:51] <jepler> http://emergent.unpythonic.net/files/sandbox/velocity-freakout.png
[13:07:46] <jepler> 9 s32 RW 10040958 hm2_7i90.0.read.tmax
[13:08:43] <jepler> 10ms = timeout for acquiring dma channel
[13:08:53] <pcw_home> ahh
[13:09:19] <jepler> I wonder, is 10ms long enough for seb's assumptions about encoder timestamp overflow not happening to simply be wrong?
[13:09:47] <jepler> /* Acquire DMA channels */
[13:09:47] <jepler> while (!acquire_dma(sdd))
[13:09:47] <jepler> msleep(10);
[13:09:56] <jepler> sigh, I'm sure whoever wrote that said to themselves, "10ms isn't very long at all"
[13:11:58] <pcw_home> 10ms should be OK for the timestamp (the timestamp rate is 1 MHz and its a 16 bit timer)
[13:14:08] <jepler> halcmd: hm2/hm2_7i90.0: (hal/drivers/mesa-hostmot2/encoder.c:999) uh-oh, encoder vel is broken with an edge
[13:14:11] <jepler> hm2/hm2_7i90.0: please email a bug report to the linuxcnc-devel list!
[13:14:14] <jepler> hm2/hm2_7i90.0: dS_counts=-1024, dT_clocks=0
[13:14:15] <jepler> now I've seen both flavors
[13:14:17] <jepler> hm2/hm2_7i90.0: prev_update_dS_counts=-31665, prev_update_dT_clocks=56490
[13:16:37] <pcw_home> wonder what about the 7I90 or SPI triggers this?
[13:16:39] <pcw_home> I haven't seen it while running the (looong running) Ethernet test
[13:17:19] <pcw_home> but the encoder counter is not being used
[13:18:22] <jepler> not enabled or not being driven with anything?
[13:18:33] <jepler> mine aren't being driven so there shouldn't be any edges
[13:19:10] <pcw_home> enabled but not connected
[13:19:24] <pcw_home> bad data maybe?
[13:19:37] <jepler> a whole corrupted read could do it
[13:19:45] <pcw_home> yes
[13:20:06] <jepler> violate any number of assumptions about how the encoder and its timestamp behave
[13:20:34] <pcw_home> may not be a bad idea to include a cookie read for a sanity check
[13:27:07] <jepler> I still think it'd be neat to read back a CRC of the transfer so far in the reply to each spi command word
[13:27:14] <jepler> then you'd know about a corruption in the middle of a transfer too
[13:30:58] <pcw_home> looking at it, it would be a bit awkward since the crc out would be a bit time behind
[13:32:25] <pcw_home> maybe better to send the RX (for read data) and TX CRC for the packet as a last 32 bit payload
[13:33:47] <jepler> time to cook some lunch and not stare at halscope until it triggers
[13:34:22] <pcw_home> Sounds good, Ill go talk to my sheep
[13:52:53] <jepler> I should rebase my branch onto master so I get the improved watchdogging
[13:55:36] <jepler> possibilities: that's slang for "take a nap"; pcw just says random things sometimes; pcw actually has sheep
[13:58:01] <micges> as it's sunday I think all of them ;)
[14:11:34] <jepler> http://emergent.unpythonic.net/files/sandbox/velocity-variations.png
[14:12:15] <jepler> when not hitting a terrible latency the computed velocity is pretty well centered around the right value
[14:13:18] <jepler> though I guess a variation of +-25m out of 1 is 2.5%, so it's not nothing either
[14:14:39] <jepler> that's the same as 25us on 1ms which is about what I get from latency-test
[14:20:08] <pcw_home> One thing that might be interesting is setting the stepgen up with the PID loop and doing a looong move
[14:20:10] <pcw_home> and recording the actual PID output (to see how well the PID does at slew limiting the corrections)
[14:28:27] <jepler> 1 hour at 2ms servo period (= 5.4 million spi transactions), no bad latencies detected
[14:29:20] <jepler> I feel like I'll never be able to declare victory, but less than 1 in 5 million sounds pretty good
[14:32:54] <pcw_home> Ive had the Ethernet stepgen stuff running pretty much continuously at 2 KHz for maybe 120 days now without error
[14:32:56] <pcw_home> so Preemt-RT is reliable and usable for 1-2 KHz servo thread loops (at least on a PC)
[14:34:15] <jepler> I wonder when we'll hear from someone actually making chips with master branch and hm2-eth
[14:34:21] <pcw_home> I expect you could do a lot better with direct hardware SPI access, (or improvements in the driver for better RT performance)
[14:34:56] <pcw_home> (but what a pain since the host side SPI hardware has no standards)
[14:34:56] <jepler> yeah, I have been steadily hacking out latency-inducing parts of the kernel drivers
[14:35:30] <jepler> the /dev/spidev API is very simple, it would be great if upstream kernels came with good-latency spi drivers
[14:35:38] <pcw_home> lair82 wants to try I think (thats one reason i fixed the resolver interface for the 7I80)
[14:36:08] <jepler> but there were problems at all 3 levels (spidev [userspace driver] -> spi [common kernel code] -> spi-s3c64xx [hardware-specific driver]) and I suspect my changes are not likely to be considered upstream in their current form
[14:36:33] <jepler> and I sure don't have any "ins" in the kernel community to even start to talk about how to make the changes upstreamable
[14:37:33] <jepler> too bad it turns out to be about politics and personal connections :-/
[14:37:55] <pcw_home> well even the preemt RT stuff is still a patch set :-(
[14:39:05] <jepler> indeed
[14:39:22] <jepler> and it sounds like the head of that project has enough on his plate as well
[14:40:49] <jepler> it was to my great amazement that the first kernel I built for the u3 that booted all the way to userspace actually had good latency -- a tribute to the preempt-rt folks
[14:41:10] <jepler> (the others didn't boot because I was fat fingering things like kernel version vs name of initrd file etc)
[14:41:32] <jepler> but after that, it's been a long slog with spi
[14:42:19] <pcw_home> I had no problems making a working preemt-rt kernel either (an d I have no real linux experience at all)
[14:45:21] <jepler> yay, lunch is ready. and holy cow was it a good idea! bagel and sausage bread pudding
[14:54:53] <jepler> huh, I had no idea there was a pissing war going on between hardkernel and rpi people. apparently hardkernel had introduced a "rpi-compatible" board (compatible header, same soc) which they have now discontinued because they say they cannot source the broadcom soc. on rpi forums, it is reported as a rumor that rpi foundation pressured broadcom to not sell that soc to anyone else (wha?)
[14:56:25] <pcw_home> Thats nice
[15:01:38] <jepler> I have no idea what a proper hardware company does as far as ensuring supply of the components they need. it does seem weird to announce a board and then shortly later announce you are giving up on it because you couldn't source the parts. on the other hand, "hand-wavy supply chain problem" is a perennial excuse of the late kickstarter project.
[15:02:07] <jepler> the dog ate my order of 10k socs
[15:04:08] <pcw_home> One reason I like FPGAs is the IP is portable so you are no stuck with one chip
[15:05:38] <pcw_home> I always thought it was strange the the 'pi used a SOC from a company with a very open-source unfriendly attitude
[15:08:40] <jepler> you'd still be stuck doing an entire new board design
[15:09:21] <pcw_home> Had enough of that...
[15:09:36] <pcw_home> and availability problems...
[15:10:04] <jepler> but you don't have the same degree of "pin 1 had better be capable of i2c and adc, and pin 3 had better be capable of serial rx and pwm" that you do when trying to make an "arduino compatible"
[15:10:22] <skunkworks_> https://groups.google.com/forum/#!topic/machinekit/ghCyQMIpUW4
[15:10:27] <pcw_home> Xilinx is pretty good about old FPGAs (Spartan II no problem)
[15:12:49] <jepler> skunkworks_: apparently some people want things like those gauges. I still don't get it.
[15:13:10] <jepler> oh wait I didn't scroll down far enough to get to the linuxcnc bashing
[15:13:11] <jepler> ctrl-w
[15:13:46] <skunkworks_> heh - I was just showing the 'new' axis
[15:14:34] <skunkworks_> 'machinetalk'/'haltalk' has been merged into machinekit.. (which solves all the problems I guess)
[15:14:44] <jepler> If I am the priesthood then where are my burnt offerings?
[15:15:16] * Tom_itx offers jepler a burnt hamburger
[15:15:46] <jepler> that's better
[15:15:48] <jepler> where's the mustard?
[15:16:00] <Tom_itx> you're pushin it now...
[15:16:38] <Tom_itx> gotta pay extra like at Mcdonalds
[15:21:41] <jepler> GRU-lab kvantoptic -- varning! laserstrålning!
http://4.bp.blogspot.com/-8PmUH9p8Z-0/VANE3_P-1II/AAAAAAAACSI/-gBiBbdp96s/s1600/ww14.jpg
[15:30:25] <jepler> hm, I'm communicating at a mere 8MHz
[15:30:28] <jepler> maybe I can safely bump that now
[15:36:36] <skunkworks_> jepler: new boards are perfect?
[15:37:15] <jepler> skunkworks_: the boards are good, the software may be getting there
[15:37:45] <jepler> skunkworks_: did you see the board shot?
http://emergent.unpythonic.net/files/sandbox/img_4904-medium.jpg
[15:39:34] <skunkworks_> that is cool!
[15:39:52] <skunkworks_> jepler: are you writing a spi driver from scratch?
[15:40:15] <jepler> skunkworks_: today's testing is with a heavily hacked linux kernel driver
[15:45:18] <jepler> everyone is invited to nebraska in 2017 for the total eclipse. my hometown is at the edge of the totality, and a friend's acreage is pretty close. I can't make any promises about the weather, though.
[15:46:44] <jepler> looks like grand island is the place to be.
[15:47:36] <jepler> or beatrice
[15:48:55] <jepler> (in nebraska anyway)
[15:50:10] <dewy721> anybody tinkering with an html frontend UI these days?
[15:51:11] <jepler> I think there may be some people doing that who are affiliated with the machinekit project. i'm not aware of anybody who is working on it for linuxcnc, though I wouldn't know about it if it were happening on the web forum
[15:53:37] <jepler> I saw this demo'd last summer but I don't know what state it's in today:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rockhopper_Web_Server
[15:54:28] <jepler> the demo included stuff like preview plot in the browser, which those screenshots don't show
[15:55:33] <jepler> ah maybe that is the "emperorweb" part? not sure
[16:03:32] <dewy721> was just over at the machinekit blog and couldn't find any info about it. Isn't the rockhopper setup just a diag tool? I'm ideally searching for a html replacement for Axis. It for the PocketNC.com machine. Witch run machinekit btw.
[16:14:07] <dewy721> <-- looks like his phone's autocowreck feature is working.
[16:16:03] <jepler> well if you want to run machinekit, this is not a great place to ask about it.
[16:17:04] <dewy721> i see. where best should i direct my inquires to?
[16:17:52] <jepler> https://groups.google.com/forum/#!forum/machinekit maybe?
[16:18:21] <jepler> unfortunately there has been a little drama between the linuxcnc project and the machinekit project; we weren't able to work it out, so the two projects are going in different directions.
[16:20:26] <dewy721> Ah thanks! You have always been handy, starting back with the etch-a-sketch machine. :)
[16:20:39] <dewy721> ttfn.
[16:20:42] <jepler> see you
[16:20:50] <jepler> you must be my one and only fan :)
[16:21:43] <dewy721> yeah, I'm odd like that. *poof*
[16:22:20] <jepler> artsy, unuseful photo of my u3 + 7i90 testing setup
http://emergent.unpythonic.net/files/sandbox/img_4910.jpg
[16:22:59] <jepler> 3 hours, 16 million SPI transactions, 0 bad latencies. time to restart the test with a faster SPI bus.
[16:42:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 33088cb 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/rs274ngc_interp.hh interp: use strings to avoid buffer hell * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=33088cb
[16:42:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master e006a24 06linuxcnc 10src/hal/hal_lib.c 10src/hal/hal_priv.h hal: an "increased" pin for thread time * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e006a24
[16:42:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 4f0f964 06linuxcnc 10(8 files in 5 dirs) rtapi: remove support for rtlinux 3.x * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4f0f964
[16:42:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master a05d29c 06linuxcnc 10scripts/rtapi.conf.in 10src/configure.in rtapi: drop support for rtai "24.x" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a05d29c
[16:42:26] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 018a0e2 06linuxcnc 10src/configure.in rtapi: drop support for alternate math libs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=018a0e2
[16:42:30] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 4ff5d6d 06linuxcnc 10src/configure.in configure: drop never-used RTAI3_MOD variable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4ff5d6d
[16:42:33] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master e485f4d 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: don't let ctrl-z stop realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e485f4d
[16:42:37] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 0516bbd 06linuxcnc 10src/configure.in configure: don't require linux/version.h * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0516bbd
[16:42:41] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 79c51c9 06linuxcnc 10src/Makefile 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=79c51c9
[16:52:20] <zq> so i was wondering, what would be the effects of running motmod on single precision hardware
[16:53:11] <jepler> zq: we used to have only single-precision types in hal
[16:53:49] <jepler> zq: we found that e.g., computing spindle velocity there wasn't enough precision after a modest number of spindle revolutions
[16:54:12] <jepler> zq: and that prompted us to figure out that we *could* use double precision for hal values
[16:54:27] <jepler> linuxcnc has *always* used double precision for internal calculations, so there are probably additional problems that would arise there
[16:54:48] <zq> jepler: internal as in rtapi_math?
[16:55:00] <zq> and friends
[16:55:23] <zq> what about the precision of cartesian movement?
[16:55:36] <jepler> zq: right, we know what it's like to use single precision for hal values .. we don't know what it's like when we use it internally like for x*y or sin(a) or whatever
[16:56:23] <jepler> I think you'll find that a lot of the math is written pretty naively; double precision (particularly, as it is on 32-bit x86, where intermediates are often carried in "long double" precision) hides a lot of flaws that show up very quickly when all intermediate values have low precision
[16:56:42] <jepler> stuff like sqrt(1-x*x) when x is not that different from 1, for instance
[16:58:05] <zq> k
[16:58:24] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 6dc693f 06linuxcnc 10src/Makefile 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6dc693f
[16:58:32] <zq> so i guess it's a matter of hunting those dithery spots and then testing it out on an sp fpu
[16:59:40] <jepler> in general we would not mind seeing the code improved in terms of adapting our algorithms to have better numeric stability
[17:01:46] <zq> actually on that note
[17:02:03] <jepler> I'm about to walk out the door so I hope it's an easy question
[17:02:04] <zq> i've been thinking of using a bit of agda on stepgen and the tp
[17:02:15] <zq> thanks for the feedback
[17:02:34] <jepler> I'm only very vaguely aware that people like to prove stuff about software
[17:02:42] <jepler> I have no idea whether the structure of linuxcnc is at all amenable to that
[17:02:51] <jepler> I would love to hear about your results
[17:03:02] <jepler> see ya
[17:14:09] <NTU> proposed-master is rockin!
[17:14:44] <NTU> i think linuxcnc is all caught up now
[18:19:30] <tjtr33> jepler, make that at least 2 fans ( 7am Monday 1 sep Taipei ) ttfn
[19:40:05] <dewy721> is there an easy'ish means to direct rw access LinuxCNC memory registers or is hal the best method for poking at it with a stick?
[19:45:09] <dewy721> I'd like to poll,buffer all the userable bits and diff-dump to a socket.
[19:58:55] <jepler> hal is full of the low-level stuff like motor positions; the exact details of that depend on the user's configuration (.hal files)
[19:59:31] <jepler> un userspace, the "status buffer", an nml thing, has all the structured information about the state of the machine. this is what the GUIs use e.g., to show the state of the DRO
[20:00:42] <jepler> halsampler is an example of a realtime component that can dump information from realtime to userspace -- it's used for example to test that the step generator behaves as expected, accurately sampling its output each realtime thread period
[20:03:03] <jepler> in non-realtime context, "halcmd show all" shows a lot of information including all hal pins and their values, but the values don't necessarily indicate a consistent snapshot of the state of hal at a particular moment.
[20:03:42] <jepler> (it might take many many times longer than the base thread's period to gather and print all that information)
[20:04:00] <jepler> so if what you want to know about is high-level, structured information then you want the status buffer
[20:04:32] <jepler> if you want to know about low-level information, then you want a component which has its inputs connected to the appropriate signals via hal; if it has to be a consistent view then it has to be a realtime component
[20:04:54] <jepler> talking about a snapshot of realtime as a whole thing is not really in keeping with the hal way of thinking.
[20:21:30] <pcw_home> halvnc!
[20:21:51] <jepler> qthtmlwebkit5vncvcp-openssl
[20:27:57] <dewy721> Ok, well since I'm targeting low-speed gpIO and pendant DRO LCD display (slow by nature) hal would probably be best then. thanks!
[20:29:37] <dewy721> halcmd that is.
[20:53:40] <jepler> you shoul write a userspace hal component and connect its pins appropriately to your use
[20:53:55] <jepler> you should not run halcmd and parse its output.
[21:04:03] <dewy721> no no. parsing all that info would be expensive. however im i need to look over the docs for making an appropriate hal component. right now I'm reading a lot of pins via a Python module and dumping them over serial.
[21:04:55] <dewy721> it's a kludge in bad need of preening.
[21:25:39] <jepler> dewy721: 'pydoc hal' includes at the top a demonstration of a simple userspace hal component that just copies its input to its output about once a second
[21:26:09] <jepler> drat, came home to another long delay doing spi transactions.
[21:26:26] <jepler> tmax of >10ms again
[21:27:48] <jepler> and it's real; velocity computed from velocity feedback is all over the map for a few cycles
[21:28:26] <jepler> realtime delay message, then watchdog message, then the encoder "uh-oh" messages
[21:30:39] <dewy721> thanks I'll look into it, when my head is up to it. allergies, tired + beer. mostly beer.
[21:30:45] <jepler> heh
[21:31:20] <jepler> have the day off tomorrow?
[21:31:38] <dewy721> yup. :)
[21:31:47] <jepler> that's good then
[21:32:13] * jepler ensures he's using the spi_s3c64xx kernel module with the last [dma] fix
[21:32:35] <jepler> I think I wasn't; I had not cpoied it to /lib/modules but I rebooted
[21:38:29] <jepler> yes, the "size" column of lsmod differs so I was definitely not running the latest and greatest spi-s3c64xx in the latest test
[22:13:24] <skunkworks_> logger[psha]:
[22:13:24] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-09-01.html
[22:13:33] <jepler> hi skunkworks_
[22:13:45] <skunkworks_> Hi
[22:13:53] <jepler> what's new?
[22:16:00] <skunkworks_> 2nd child seems to be on the way... That is new.. :)
[22:17:03] <jepler> oh! congratulations!
[22:19:18] <skunkworks_> Thanks - a bit early - due around april
[22:19:57] <zq> man, i feel so behind
[22:24:59] <jepler> well I shouldn't sit here all night just waiting for halscope to trigger
[22:25:04] <jepler> goodnight all
[22:25:04] <skunkworks_> heh
[22:25:07] <skunkworks_> good luck
[22:25:39] <jepler> each time a bad latency pops up I realize I have a lot of emotional investment in this project now
[22:25:42] <jepler> :-/
[22:26:17] <jepler> (not that it's all bad, but geez who gets emotional over a computer taking 10ms to do something)
[22:28:44] <skunkworks_> been there
[22:33:18] <mozmck> skunkworks_: congratulations!
[22:38:26] <skunkworks_> mozmck: thanks!
