Back
[01:04:03] <cmorley> So ran across 'gitit' program - curious could that be used to make HTML / pdf docs from a wiki page?
[01:04:55] <cmorley> Thinking a user could make / edit a page and then send a pull request to us for possible inclusion...
[01:05:41] <cmorley> Anything to get more people to help documenting.... it's tedious :)
[01:05:44] <cmorley> night
[07:29:32] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/moveoff 4d9eaae 06linuxcnc 10configs/sim/axis/moveoff/moveoff_gui.tcl 10src/hal/components/moveoff.comp moveoff.comp: disable offsets when resume detected * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4d9eaae
[09:22:21] <seb_kuzminsky> i just ran dgarr's moveoff sim config, it looks like a promising start
[09:24:11] <seb_kuzminsky> nice, "moveoff.com: ERROR: Program resumed before offsets removed"
[09:25:36] <skunkworks> heh - I was just compiling it..
[09:25:48] <dgarr> dgarr/moveoff demo2
http://youtu.be/8QGOj39I-kk i have to go but will read back if there are comments
[09:25:52] <dgarr> bbl
[09:29:09] <jepler> .com ?
[09:31:17] <skunkworks> comp...
[09:38:16] <seb_kuzminsky> p
[09:41:35] <seb_kuzminsky> we're gonna get confused emails about the DRO not changing, but what can you do
[09:41:48] <seb_kuzminsky> dgarr: please pute moveoff in the 2.7 branch
[09:42:04] <skunkworks> heh
[09:48:47] <skunkworks> the axis preview needs an offset input... ')
[09:48:50] <skunkworks> ;)
[09:49:40] <cradek> having the programmed position and offset displayed separately actually feels kind of featurey to me
[09:50:12] <cradek> because that's really how you think about them
[09:52:29] <seb_kuzminsky> hmm, i can see that point
[09:52:50] <skunkworks> the only issue I see is it will screw with your softlimits..
[09:53:48] <cradek> it's true
[09:54:06] <cradek> but I think it's probably ok
[09:54:29] <skunkworks> it will only come into play with really small travel machines probably...
[10:19:45] <skunkworks> Dad found out on the matsura when feed hold is on - you can turn the jog wheel - the numbers move on the screen but the physical axis doesn't..
[10:20:04] <skunkworks> feature by design?
[11:52:40] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 9c2171b 06linuxcnc 10docs/src/index.tmpl docs: minor reorg in the html index * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9c2171b
[12:27:05] <jthornton> I got an error on 10.04 with moveoff and have notified dgarr
[16:56:13] <seb_kuzminsky> oops, i hope dgarr doesn't mind that i've been talking about his new "offset-while-paused" feature in public
[17:07:26] <Tom_itx> too late now
[17:09:54] <seb_kuzminsky> yeah :-/
[17:10:09] <seb_kuzminsky> well he *did* push it to a public repo, and upload a demo to youtube
[17:10:22] <seb_kuzminsky> and folks were talking about it on the list, so... i think its ok
[17:15:32] <tjtr33> i've used the offset comp and an analog voltage to move during a pause, and have a comp that reduces the offset till it's 0. does dgarr come in here?
[17:16:25] <tjtr33> i think you could just manually get close and push the 'getBackHomeLoretta' button and then continue
[17:16:39] <seb_kuzminsky> dgarr's moveoff trick is a hal component that gets inserted just before the joint controller
[17:16:56] <seb_kuzminsky> while motion is paused, you can add an arbitrary offset to each joint
[17:17:22] <seb_kuzminsky> the joint moves according to these offsets you introduce (while obeying vel & acc limits)
[17:17:46] <seb_kuzminsky> when you want to resume you undo the offsets (or click the button that asks moveoff to undo them for you), then unpause the program
[17:18:10] <tjtr33> i dont prescribe the offset, i just jog, then redcue to 0 before returning control to Linuxcnc. i watched the demo. does he come in here?
[17:18:17] <tjtr33> reduce
[17:18:23] <seb_kuzminsky> things like spindle control, coolant, etc all respond as normal
[17:18:31] <seb_kuzminsky> dgarr comes to this irc channel occasionally
[17:18:41] <tjtr33> ok thanks!
[17:21:06] <tjtr33> scusa, where is this public repo withhis code?
[17:23:09] <seb_kuzminsky> it's the dgarr/moveoff branch at git.linuxcnc.org
[17:23:39] <seb_kuzminsky> when i checked this morning it had a slightly older version of the code than what's in the demo video, but maybe he's updated it
[17:24:03] <seb_kuzminsky> it might be best to wait until he announces it to try it out? he's not actually asked for beta-testers yet....
[17:24:17] <tjtr33> again thanks ( ima in Wheat Rdige next Tuesday :)
[17:24:48] <tjtr33> I'd like to offer what I've bult and used to Dewey et al
[17:25:20] <tjtr33> no need to use it for edm like me, no need for analog voltage
[17:27:09] <tjtr33> ok, browsing the branch now, thx
[17:28:12] <tjtr33> wow a tickle gui too
[17:35:54] <tjtr33> hmm i dont see the moveoff comp itself in linuxcnc.git /configs /sim /axis/moveoff/ i see a hal file that loadrt's it, but not the comp code itself
[17:37:01] <tjtr33> ah linuxcnc.git] / src / hal / components / moveoff.comp
[17:42:52] <tjtr33> he unlinks a std cfg, & grafts in the new comp, very nice!
[17:43:20] <tjtr33> so velocity and acc are controlled as normal. I gotta build it to prove to myself if it moves at jog or F rates.
[17:43:36] <tjtr33> nice work Mr Garret!
[17:47:56] <andypugh> I can see that HAL is one way to do Jog-while-paused, but it doesn’t seem to me to be the “right” way.
[17:48:43] <tjtr33> instead of entering an offset, i had a very small unit of change ( say .0001") and i added that to the offset while a btn was held.
[17:48:55] <andypugh> I imagine it can be made to look very similar with jogwheels paralleled to both normal jog and jwp component, but I assume that it can’t be made to follow keyboard jogs?
[17:49:24] <tjtr33> I kept track of the offset and reduced that towards 0 with another btn. as many buttons and axis as you like.
[17:51:03] <seb_kuzminsky> andypugh: i agree, this is a quick way to get jwp-like behavior without adding anothe rlayer of hackery to Task
[17:55:40] <andypugh> Because the intention is to do something cleverer with Task? Why is Task hackery deprecated?
[17:56:11] <seb_kuzminsky> task is a bit of a mess
[17:56:44] <seb_kuzminsky> it's gotten quite brittle, it's hard to add new features to task without breaking some of the old features
[17:56:56] <andypugh> I have thought for quite a while that an external offset pin for each axis would be useful at times, one that gets applied inside the axis limits.
[17:57:20] <andypugh> I guess without that the new JWP component will be joint-jogging not axis jogging?
[17:57:39] <seb_kuzminsky> for example, the addition of mdi queueing introduced a bug in state signalling that went hidden for over a year, and took serendipity to discover and a week of debugging to fix
[17:57:57] <seb_kuzminsky> yes, it operates on joints, not axes
[17:58:38] <andypugh> So not really compatible with the JA concept?
[17:58:58] <seb_kuzminsky> so i'm reluctant to make or encourage any large changes to task, because i'm not confident that we could do it without breaking stuff
[17:59:31] <seb_kuzminsky> i'm not sure what you mean... dgarr/moveoff and JA are independent
[17:59:58] <andypugh> I was talking of the “concept” of joints and axes being different.
[18:00:49] <seb_kuzminsky> to do jwp in the best way we'd want to tie it in with the existing jog machinery, and then presumably we'd be able to do jwp in joint mode or world mode, just like we can with jog-while-not-paused today
[18:01:19] <andypugh> My worry is that the jwp component means that that won’t get done.
[18:01:35] <seb_kuzminsky> well that may be...
[18:01:51] <andypugh> I know I actually suggested a component for the job, but I have gone off the idea.
[18:02:14] <seb_kuzminsky> but i'd rather have something that fixes a percieved problem for our users with minimal risk, rather than do a high-risk change or to wait for the task cleanup
[18:02:56] <seb_kuzminsky> i think dgarr's 90%-solution to the jwp problem, using a comp between motion and the joint controller, is a great interim solution
[18:03:22] <seb_kuzminsky> part of why i'm working on lui is that it paves the way for the task cleanup in the future
[18:04:16] * seb_kuzminsky shrugs
[18:04:18] <seb_kuzminsky> bbl!
[18:26:14] <seb_kuzminsky> linuxcnc-build: force build --branch=master 2000.docs
[18:26:15] <linuxcnc-build> build #2183 forced
[18:26:15] <linuxcnc-build> I'll give a shout when the build finishes
[18:35:23] <linuxcnc-build> Hey! build 2000.docs #2183 is complete: Warnings [8warnings compile]
[18:35:24] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/2183
[18:35:35] <seb_kuzminsky> yay
[18:35:39] <seb_kuzminsky> good job little robot
[18:37:13] <seb_kuzminsky> i just brought this back to life:
http://buildbot.linuxcnc.org/doc/
[18:37:22] <seb_kuzminsky> built docs from non-release branches
[18:37:56] <seb_kuzminsky> in preparation for some docs work i'm cooking up for the 2.7 release
[18:38:29] <seb_kuzminsky> hi skunkworks
[18:41:53] <skunkworks> seb_kuzminsky: Hi
[18:50:18] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/moveoff f287c4c 06linuxcnc 10configs/sim/axis/moveoff/moveoff_gui.tcl 10src/hal/components/moveoff.comp moveoff: rtai: no use struct for lim3() outputs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f287c4c
[20:39:47] <cradek> cmorley: in parport.comp you use bitwise xor to generate "not" values for hal pins. since hal bits are integral C types you should use ! instead
[20:42:30] <cradek> cmorley: I think you have written a bug where a hal pin with value 2 (which is hal "true") ^1 (which you intend to be an invert) will give you 3 (still hal "true")
[20:48:02] <jepler> this concern may be partially outdated, because in 2.7+ the underlying type of hal_bit_t is a boolean. in older versions, it was an integral type (unsigned char). 606d8328f683 hal: Introduce hal_bool, use it for hal_bit_t
[20:48:19] <jepler> if x and y are bool, then I believe x ^ y does what is desired
[20:48:29] <cradek> oops thanks
[20:48:45] <jepler> but if either of them is not a bool, then x ^ y does something other than what is intended
[20:49:35] <jepler> I think x ^ 1 also gives what is intended
[20:50:35] <jepler> so this program prints 1\n0\n
[20:50:48] <jepler> http://paste.debian.net/133552/
[20:51:09] <jepler> in the case of the first expression, 2^1, it gets 3 which is true (1) when converted to bool
[20:51:46] <cradek> so it seems the code is fine, my mistake
[20:52:11] <cradek> which C introduced boolean types?
[20:53:09] <jepler> C99, I think
[21:01:24] <jepler> if x and y (integers of whatever stripe) hold either 0 or 1, then x ^ y is either 0 or 1.
[21:02:26] <cradek> yes I recall hal_parport inputs used to be other than 0 or 1 (there were several related bugs)
[21:02:31] <jepler> the other caveat is that if you store a value that is is neither 0 or 1 in the memory allocated for a bool, your program has undefined behavior (for instance if you do it with memset)
[21:04:33] <jepler> but bool b = 36; is just fine (stores 1 in b)
[21:05:42] <skunkworks> I thought I took a video of the linuxcnc finding a circle and then centering it in the view.. but I guess I fail at phone videos.
[21:06:39] <jepler> skunkworks: boo
[21:08:01] <skunkworks> I am not happy with opencv circle finder.. either I don't know the correct settings - or it just sucks. The circle is very round nice contrast but it will find a circle that is 4+ pixels off...
[21:08:21] <skunkworks> (and a different size)
[21:09:43] <skunkworks> internet has been no help. the only thing I have found reference to is use a blob detector - then there is a fit circle function that supposedly works better.
[21:16:32] <jepler> that stuff is all way over my head
[21:21:12] <jepler> I've been having fun with a quadcopter all week. "nano qx", it's low end but one that reviewers said didn't break the first time you crash it (and you will crash it, over and over again)
[21:21:50] <jepler> the main problem is you don't get much flying time per charge
[21:23:02] <skunkworks> I have been trying to stay away from those...
[21:23:22] <jepler> my cats try to stay away from it too
[21:25:10] <skunkworks> I bet - those things are not quiet
[21:27:23] <skunkworks> dad hasn't even hooked up his mazak yet.. we don't know if it will 'just work'
[21:27:57] <jepler> is it supposed to "just work"?
[21:28:17] <jepler> it would be terrible if you didn't have to retrofit it with linuxcnc
[21:30:21] <skunkworks> I know - right?
[21:30:58] <jepler> Motor Size: 6mm brushed coreless
[21:31:08] <skunkworks> I think it was 'working when taken out of service about 6 months ago..)'
[21:31:30] <skunkworks> it is unreal what they can do now...
[21:31:31] <cradek> heh
[21:31:53] <cradek> yeah we decided to stop using it for NO REASON at all
[21:32:00] <jepler> I dunno what RPMs they operate at, but it sounds like a small swarm of bees or something
[21:33:25] <jepler> cradek: sounds about right
[21:33:25] <skunkworks> it really looks nice.. we think it may have been in a r&d or such department.. lots of blueprints for pipe bending machines.. (this company makes large air conditioning units)
[21:34:11] <skunkworks> brushed servos... (Yay..)
[21:34:47] <jepler> Rated Torque 0.05 mNm
[21:34:50] <jepler> https://catalog.precisionmicrodrives.com/order-parts/product/106-002-6mm-dc-motor-12mm-type
[21:35:03] <jepler> write 50 µNm, it sounds better than .05 of something
[21:35:14] <jepler> 14krpm
[21:36:10] <skunkworks> you know that is the gateway drug.. next you will be creating your own quad copter - because you can do it better!
[21:36:40] <jepler> I have been doing a little investigating of whether it's possible to replace the software
[21:36:55] <skunkworks> umm hmm
[21:36:57] <jepler> so far I've learned that the remote has an atmega and the copter itself has an ARM (STM32)
[21:37:41] <jepler> the STM32 should have a bootloader available, but I'd have to start from scratch on software (or adapt existing open source software, some do exist for open source hardware)
[21:37:50] <jepler> and how hard could it be? I know all about PID loops
[21:39:57] <Connor_mill> okay pcw_home or anyone else.. what's the command to flash the 5i25? need to load it up with 5i25_7i76x2r.xml file.
[21:42:00] <skunkworks> mesaflash --device 5I25 --write FPGAFILE.BIT
[21:42:20] <skunkworks> (not the xml file..)
[21:42:50] <jepler> like skunkworks says, you need a .bit (or .BIT) file, not a .xml file. the .xml file is just a description of the capability of each pin under that firmware, similar to a .pin file but machine-readable
[21:43:57] <Connor_mill> I have the bit file.. okay.. got it..
[21:44:09] <Connor_mill> now.. to power off the machine and kill power to mobo...
[21:44:12] <Connor_mill> then start back up?
[21:44:44] <jepler> does mesaflash --reload work with --device 5I25 ?
[21:45:16] <Connor_mill> I don't see the --reload command in mesaflash.
[21:45:20] <skunkworks> well.. i think the latest mesa flash - you don't have to.. but if you have the time - it might be safer to just shut it down..
[21:45:27] <jepler> .. if --reload is not available, then yes you would need to fully power cycle the PC
[21:45:32] <Connor_mill> okay.. brb
[21:45:33] <Connor_mill> quit
[21:47:30] <Connor_mill> okay. back.
[21:47:54] <Connor_mill> anything special I need to do now? getting ready to run pncconf
[21:49:13] <skunkworks> I have never un pnfconf
[21:49:23] <skunkworks> pncconf
[21:57:09] <pcw_home> --reload will only be available if the previous bitfile was new enough to have the ICAP feature
[21:57:30] <Connor_mill> okay.. pncconf ran.. no fire from my stepper..
[21:57:39] <Connor_mill> what to look for..
[21:58:20] <Connor_mill> I'm using the 5i25_7i76x2r.bit bit file...
[21:58:33] <Connor_mill> and using the internal header on the 5i25 card...
[21:58:44] <pcw_home> you can verify the pinout with
[21:58:45] <pcw_home> sudo mesaflash --device 5i25 --readhmid
[21:59:04] <Connor_mill> what color should the LED be?
[21:59:44] <pcw_home> there should be no 5I25 LEDs on
[22:00:01] <Connor_mill> on the 7i76
[22:00:26] <pcw_home> there should be 2 yellow LEDs on
[22:00:55] <Connor_mill> I only see CR2 on
[22:01:46] <pcw_home> no CR1 means no 5V
[22:02:14] <Connor_mill> okay. so.. I have something jumpered wrong then
[22:02:34] <Connor_mill> I have +12v for field voltage, was going to use 5v from the 5i25
[22:03:10] <pcw_home> you need 7I76 CR2 LEFT and 5I25 W1 UP
[22:03:29] <pcw_home> 7I76 W2 LEFT I mean
[22:03:55] <Connor_mill> W2 is left.
[22:04:00] <Connor_mill> W1 is down
[22:04:15] <Connor_mill> can I change that while powered or do I need to power down ?
[22:04:48] <pcw_home> I wouldn't change it hot
[22:04:53] <Connor_mill> okay. brb
[22:05:07] <pcw_home> (well I would but not to a customer board)
[22:05:49] <pcw_home> we host plug our test boards all the time but never production cards
[22:05:58] <pcw_home> s/host/hot/
[22:08:41] <Connor_mill> and we have movement on Z! :)
[22:09:51] <Connor_mill> Good greif.. pncconf takes FOREVER to load
[22:19:44] <Connor_mill> how do you get follow errors with steppers ?
[22:24:28] <skunkworks> steppers in linuxcnc are run similar to servo's... The have a position loop that gets adjusted every servo cycle
[22:25:06] <Connor_mill> okay. but, how does lcnc know the stepper didn't move the correct amount ?
[22:26:23] <skunkworks> it doesn't know externally.. it knows internally. like if you don't have the 5i25's stepgens accelleration set higher than the motion planners..
[22:26:52] <skunkworks> the 5i25 will fall behind and you get a following error
[22:30:26] <Connor_mill> okay
[22:44:53] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/moveoff 26c2b50 06linuxcnc 10(7 files in 2 dirs) moveoff.comp: Suport increment radiobuttons * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=26c2b50