Back
[08:15:29] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid commented on issue #86: This workaround is unnecessary . The problem existed only when there were not the correct .glade files.... 02
https://github.com/LinuxCNC/linuxcnc/issues/86#issuecomment-243752805
[08:40:12] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #86: @nicokid thanks for noting that! If you prepare a pull request that reverts ffc5fb9 and double check that the axis pages work properly, I'll merge it. I can't do that testing right this second. 02
https://github.com/LinuxCNC/linuxcnc/issues/86#issuecomment-243759163
[09:35:42] <seb_kuzminsky> "ready for cautious usage":
https://github.com/dinuxbg/gnupru
[09:47:33] <jepler> neat!
[09:47:37] <jepler> are you about ready to do some PRU coding?
[10:00:55] <skunkworks_> is this in regards to the BBB pru?
[10:22:35] <pcw_home> Probably any newer Sitara PRU (including the CPU on the BBB)
[10:22:58] <skunkworks_> pcw_home, cool
[10:25:09] <seb_kuzminsky> jepler: yeah i think so
[10:25:15] <seb_kuzminsky> skunkworks_: yeah, it's for the bbb
[12:43:13] <seb_kuzminsky> the bbb kernel needs a patch to load pru firmware built by the gnu-pru tools, and i still dont have my bbb kernel workflow up and running :-(
[12:52:32] <jepler> it is a different format than what comes out of the "regular" tools?
[12:52:39] <jepler> maybe you need a format converter instead?
[13:06:31] <seb_kuzminsky> + /* GNU binutils do not support multiple address spaces. The
[13:06:31] <seb_kuzminsky> + * default linker script from the unofficial GNU pru-ld places
[13:06:31] <seb_kuzminsky> + * IRAM at an arbitrary high offset, in order to differentiate it
[13:06:34] <seb_kuzminsky> + * from DRAM. Hence we need to strip the artificial offset
[13:06:37] <seb_kuzminsky> + * from the IRAM address.
[13:06:39] <seb_kuzminsky> + */
[13:06:52] <seb_kuzminsky> i guess the ti linker handles that
[14:16:48] <jepler> 8 s32 OUT 48699 servo.latency-max
[14:16:55] <jepler> still nice latency from the xu4 overnight + half the day
[14:31:42] <skunkworks_> that is very nice!
[14:32:15] <skunkworks_> do you have an spi daughter board already made up?
[14:34:40] <skunkworks_> is the ethernet usb?
[14:36:46] <skunkworks_> Can you dynamically set the processor speed? (lowering it would help the heat trottle problem)
[14:38:03] <skunkworks_> Throttle
[15:10:06] <seb_kuzminsky> that's great jepler
[15:10:13] <seb_kuzminsky> xenomai or rt-preempt?
[15:22:46] <jepler> seb_kuzminsky: rt-preempt
[15:22:51] <jepler> the ethernet is usb
[15:23:01] <jepler> there's a bunch of control that can be exercised over CPU speeds in /sys
[15:23:20] <jepler> yes, the ethernet is usb. I have a PCB waiting for fabrication to hook the spi to a 7i90
[15:29:52] <seb_kuzminsky> schwing!
[18:22:16] <kwallace2> In G76 there is this code to condition the compond angle entry:
[18:22:16] <kwallace2> double compound_angle = block->q_number;
[18:22:17] <kwallace2> if(compound_angle == -1) compound_angle = 0;
[18:22:17] <kwallace2> compound_angle *= M_PIl/180.0;
[18:22:17] <kwallace2> if(end_z > start_z) compound_angle = -compound_angle;
[18:22:17] <kwallace2> The second line seems to indicate that -1 degree is a special case. My understanding is that any number should be okay, am I missing something?
[18:33:10] <kwallace2> Hmm, I think the second line is trying to set a default angle of 0 if a Q word is not in the command or doesn't have a value?
[18:48:25] <kwallace2> I think this is what I want:
[18:48:30] <kwallace2> if(block->q_flag) {
[18:48:30] <kwallace2> double compound_angle = block->q_number;
[18:48:30] <kwallace2> } else {
[18:48:30] <kwallace2> double compound_angle = 0;
[18:48:30] <kwallace2> compound_angle *= M_PIl/180.0; // convert from degrees to radians
[18:48:31] <kwallace2> if(end_z > start_z) compound_angle = -compound_angle;
[19:04:46] <kwallace2> or maybe: double compound_angle = block->q_flag ? block->q_number: 0;
[21:01:37] <jepler> it looks like there are several sites that check q_number against -1, but that does seem silly when there is q_flag.
[21:01:48] <jepler> I didn't search enough to find out whether q_number was invented before q_flag
[21:02:35] <jepler> if you plan to change it and would like to contribute it to linuxcnc, I suggest (A) change all sites in one commit (B) change only that in one commit
[21:02:47] <jepler> so don't mix it with other functional G76 changes in the same commit
[21:05:27] <jepler> gitk is failing me at following the history of that file back that far
[21:06:57] <jepler> q_flag was added at commit 7ed7a64c8446 (2010) while q_number existed back to the dawn of time
[21:07:20] <jepler> g76 was added in 2006 at commit 0e06ee0ac1e3
[21:07:28] <jepler> so yeah that is why, q_flag didn't exist
[21:07:35] <jepler> and when I added it, I didn't find/convert all code comparing q to -1
[21:08:30] <jepler> 8 s32 OUT 48699 servo.latency-max
[21:17:33] <cradek> I bet Q was an integer before then; integer-only words didn't/don't have flags
[21:18:11] <jepler> kernel/rtmutex.c:1991:1: note: expected ‘struct ww_acquire_ctx *’ but argument is of type ‘struct ww_acquire_ctx *’
[21:18:14] <jepler> well that's a confusing message
[21:28:00] <jepler> boo latency went to 185us while I was building a kernel
[21:31:58] <jepler> Kernel: arch/arm/boot/zImage is ready
[21:34:09] <jepler> and then much twiddling ensues while waiting for a deb to appear
[21:36:17] <jepler> https://lwn.net/SubscriberLink/698315/530a16e563e67d67/ (Atomic usage patterns in the kernel)
[21:40:05] <kwallace2> Thank you for the insight into G76 code. Checking for -1 seemed strange to me since -1 is part of the valid value set. I am used to 30 degrees, but I have found references to values around 0 for Acme and square threads. So using -1 degrees might be an issue for someone along the way.
[21:41:19] <cradek> didn't jepler change *everything* to flags? I thought we got rid of the special -1s.
[21:41:34] <cradek> maybe it was just an oversight
[21:52:57] <jepler> welp that's not working so well. gets to the graphical login prompt now, but not to the desktop. and typing a key on the serial terminal makes chunks be blown.
[21:53:19] <jepler> oh wait it does reach the desktop
[21:53:26] <cradek> jeez
[21:53:34] <jepler> I got fooled by the same thing that got skunkworks the other day: the openbox "desktop" is just a blank grey window
[21:53:45] <cradek> ha
[21:53:48] <jepler> plus this wireless mouse goes to sleep and waggling it does nothing
[21:54:37] <cradek> that's not the best feature for a mouse
[21:55:15] <jepler> no it's not
[21:55:55] <jepler> latency test results look the same as remote, for 1 minute anyway. and axis with 3D_Chips loaded rotates and zooms relatively fluidly
[21:56:08] <jepler> whee.
[21:56:40] <cradek> it's a computer!?
[21:56:52] <jepler> kernel pushed to
https://github.com/jepler/odroid-linux/tree/odroidxu3-3.10-y-rt
[21:57:16] <jepler> I expect to have to do battle with spidev latency once I have the little adapter boards in hand, but that may not be for 2 weeks yet
[21:57:43] <cradek> nice progress!
[21:57:54] <jepler> yes!
[21:58:41] <jepler> and it'll be encouraging to have hm2_bbspi, in case I get tired of messing with the kernel driver I can *probably* go down to register level in userspace like that one does (but with totally different hardware registers, I'd have to find the docs for this chip)
[21:59:29] <cradek> neat
[21:59:38] <cradek> two possibilities to make it useful
[21:59:43] <cradek> no glaring problems with the hardware yet?
[22:02:03] <jepler> I worry the thermal problem will be worse with the daughtercard, it sits above the fan and so it can't help reducing airflow
[22:02:31] <jepler> everything's raw around the edges, of course; the kernel update process deletes a critical file half the time and I haven't figured out why yet
[22:02:46] <jepler> you have to make a pact with the devil to get the register datasheet for the CPU
[22:03:19] <cradek> bleh
[22:04:37] <jepler> "just read the kernel source, you can probably learn what you need"
[22:07:08] <jepler> oh interesting, it looks like it is the same SPI kernel driver as the older odroid
[22:07:15] <jepler> CONFIG_SPI_S3C64XX=m
[22:07:36] <jepler> so with any luck I can just forward-port my latency patches (old kernel was 3.8, I think; this is kernel 3.10)
[22:07:43] <cradek> cool
[22:07:45] <jepler> well that's enough progress for one night.
[22:07:49] <cradek> g'night
[22:07:58] <jepler> (not a huge surprise they are both samsung exynos family CPUs)