Back
[00:01:24] <mshaver> Even with a infinite number of monkeys and typewriters I don't think I could have come up with that!
[00:02:15] <mshaver> So, I build this comp (and it looks like there's some man page stuff in there as well) and it controls the motor?
[00:02:41] <mshaver> Do you have an example hal file that uses this?
[00:11:15] <andypugh> Give me a moment, and be warned that it is a total lashup
[00:13:36] <andypugh> Hmm, actually, it's too much of a lashup at the moment.
[00:14:10] <andypugh> What is your motor configuration? I will make up something sensible.
[00:14:28] <cradek> jepler: awesome, thanks for making the release.
[00:15:31] <mshaver> It's a 1kw brushless motor of unknown characteristics with a 500 line encoder (2000 counts/rev)
[00:15:46] <andypugh> encoder only, no hall sensors?
[00:16:09] <mshaver> it also has 3 hall sensors, but they're not hooked up to anything right now
[00:16:20] <andypugh> Do you want to use them?
[00:16:37] <andypugh> The options are:
[00:16:39] <mshaver> I don't really know
[00:16:44] <andypugh> Use the encoder, home to index
[00:16:55] <andypugh> Use the encoder, home to a known motor state
[00:17:26] <andypugh> Use the hall sensors, start in hall commutation, home on the first transition and switch to sinusoidal
[00:17:49] <andypugh> Use the hall sensors, but home to encoder index
[00:18:18] <andypugh> The latter is the best, I think.
[00:18:41] <andypugh> the second is the easiest with a loose motor.
[00:19:03] <mshaver> I don't (at the moment) have an easy way to hook up the hall sensors, so if I can avoid them for now that would be good.
[00:19:59] <andypugh> OK :-)
[00:19:59] <mshaver> The encoder was not installed with any particular respect to the rotor orientation, just so you know...
[00:20:08] <mshaver> if that matters.
[00:20:28] <mshaver> as you may suspect, I have no idea what I'm doing!
[00:20:47] <andypugh> That's fine, for the moment you can home magnetically, but it is not the best method.
[00:27:12] <andypugh> do you know how many poles the motor has?
[00:28:29] <andypugh> This should get you close
[00:28:30] <andypugh> http://www.pastebin.ca/2003370
[00:30:02] <mshaver> no idea on the poles, sorry
[00:30:15] <andypugh> It matters, a lot
[00:31:10] <andypugh> With the 8i20 powered up but off you can probably feel them. It's how many notches you can feel as you turn the shaft.
[00:31:32] <andypugh> (x 2)
[00:32:19] <mshaver> what pin/param is affected by the number of poles?
[00:34:12] <mshaver> * mshaver has to build the comp (after re-remembering how), hook up power to the 8i20, and then get this hal file running with my 5i20 setup
[00:35:09] <andypugh> The driver runs in terms of electrical revolutions, but the encoder measures shaft revolutions
[00:35:24] <andypugh> building the comp is easy. comp --install bldc.com
[00:35:34] <andypugh> (bldc.comp)
[00:35:53] <andypugh> The bldc.0.poles parameter sets the ratio
[00:36:08] <andypugh> It will be 4, 6 or 8
[00:38:17] <mshaver> OK! This will take a while. I'll get back to you tomorrow (it's 7:37pm for me and half past midnight for you I think) Thanks!!
[00:38:31] <andypugh> Have fun
[00:38:55] <mshaver> I can't wait!
[00:41:24] <cradek> jthornton: are you working on fixing time.comp? or do you want me to do it?
[00:47:11] <cradek> I fixed it
[00:47:11] <CIA-2> EMC: 03cradek 07master * r7d2b3445fb24 10/src/hal/components/time.comp: Fix build on sim, which doesn't have a u32 type
[00:47:13] <CIA-2> EMC: 03cradek 07master * r80827933e550 10/src/emc/usr_intf/touchy/emc_interface.py: Clarify
[00:47:15] <CIA-2> EMC: 03cradek 07master * rba9e6d7b623c 10/src/emc/usr_intf/touchy/touchy.py: Fix runtime error and support old configs
[00:47:16] <CIA-2> EMC: 03cradek 07master * r84c5cfdea8d6 10/src/emc/usr_intf/touchy/ (hal_interface.py touchy.py): Fix jog increments for mm and degrees
[00:47:17] <CIA-2> EMC: 03cradek 07master * r0c29e2aca088 10/src/emc/usr_intf/touchy/touchy.py: Increase maxvel wheel increment on mm machines
[00:47:22] <CIA-2> EMC: 03cradek 07master * r6a766253bd14 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.py): Let Touchy correctly handle unit conversion
[01:51:02] <jepler> cradek: thanks for fixing that
[01:51:11] <jepler> I apparently got bored before actually pushing the fix I'd made over here..
[02:43:37] <andypugh> What do you get when you do a bitwise & on a signed ints?
[02:54:56] <jepler> Some operators (the unary operator ~, and the binary operators <<, >>, &, ^, and |, collectively described as bitwise operators) are required to have operands that have integer type. These operators yield values that depend on the internal representations of integers, and have implementation-defined and undefined aspects for signed types. -- draft C99 standard
[02:55:25] <andypugh> That could be the problem then.
[02:56:06] <jepler> in practice, all machines you'll run into use "two's complement" and treat the sign bit just like any other bit
[02:57:08] <andypugh> I have been staring at
http://www.pastebin.ca/2003440 all night
[02:57:37] <jepler> what is arctan() ?
[02:57:41] <andypugh> A[0] is a slightly noisy 0 to 1023 "arctan"
[02:58:19] <andypugh> It's a 4-quadrant integer arctan
[02:58:29] <jepler> A[0] is negative sometimes?
[02:58:33] <andypugh> Never
[02:59:07] <jepler> and what's B?
[02:59:17] <andypugh> a signed long
[02:59:30] <jepler> what's the interpretation of the value in B?
[02:59:48] <andypugh> It just stores the previous value of R
[02:59:58] <andypugh> R is my resolver position
[03:00:16] <jepler> oh, you're trying to count multiple revolutions up and down
[03:00:20] <andypugh> Yes
[03:03:46] <andypugh> But what I seem to get is this:
http://www.imagebin.ca/view/mRNjJ9.htm
[03:04:24] <andypugh> Which was actually a steady movement in one direction.
[03:07:52] <jepler> is this your microcontroller resolver board talking to a hostmot2 encoder counter, or a hostmot2 resolver that names itself an encoder?
[03:08:10] <andypugh> That code runs on the microcontroller
[03:08:27] <jepler> the one that outputs quadrature?
[03:08:52] <andypugh> The R value is "chased" by a counter which cycles through quadrature codes
[03:09:31] <andypugh> I do have a version that works, this was meant to be a better solution and to allow me to add a tracking filter.
[03:09:47] <jepler> do you have a way to know whether it's this R-computing code or the chase code that is flawed?
[03:10:34] <andypugh> (The other version lets R wrap, and then the counter always tries to take the shortest route, with code to see that through zero might be shorter)
[03:10:48] <andypugh> Not really.
[03:11:24] <andypugh> I can print them all to serial, but that makes it all work perfectly, apart from being too slow to be at all useful
[03:12:11] <jepler> print R to serial
[03:12:26] <jepler> that makes me think that the code you pastebinned is right, and the chasing code is wrong..
[03:12:54] <andypugh> The chasing code is very, very simple.
[03:13:37] <andypugh> If (Q < R) Q++ else if (Q > R) Q--
[03:13:40] <jepler> I converted your code to python and it works -- so either I accidentally fixed the bug, or it's right, or the bug is some low-level C thing that I'm not thinking of either
[03:14:47] <jepler> well, except that it counts the opposite direction .. I wonder why
[03:15:22] <andypugh> Which one counts the opposite direction?
[03:16:05] <jepler> http://pastebin.ca/2003446
[03:16:20] <jepler> when the rotation of the input is positive it's counting negative, and vice versa
[03:16:55] <jepler> oh, durrrrr, I need to call sin() and cos() with radians
[03:17:51] <jepler> http://pastebin.ca/2003453
[03:18:24] <andypugh> It possible that ~1023 is a different bit pattern to 0xFFFFFFFC00
[03:19:16] <andypugh> I wonder if I need to mask out the possibility of a sign-bit in A?
[03:19:29] <jepler> in Python they are different (~1023 is negative, 0xFFFFFC00 is positive)
[03:19:41] <jepler> you told me A is strictly 0..1023
[03:19:48] <andypugh> Well, yes.
[03:20:32] <andypugh> I am grasping at straws
[03:21:09] <andypugh> I thought it had the possibility of being 1024 sometimes, and took that out.
[03:22:59] <jepler> above the button for channel 11, there's a little spike of about 1/3 or 1/4 div
[03:23:18] <andypugh> The very odd thing is that the motor was turning at <1 Hz in that plot, and the problem was happening at rather more frequent intervals (0.3 seconds)
[03:23:44] <cradek> how many counts are the jumps?
[03:23:56] <cradek> (one is twice as big as the rest)
[03:24:13] <jepler> cradek: 1K/div, so they're about the +-1024 that can be added/subtracted from R
[03:24:19] <cradek> oh they're 1024
[03:25:31] <jepler> what if the bug is reading the resolver angle wrong sometimes -- sometimes (half the time?) a wrong reading would make you wrongly jump by +-1024
[03:26:03] <andypugh> That spike is 390....
[03:26:13] <andypugh> Maybe that's the problem
[03:26:40] <andypugh> (It's definitely _a_ problem)
[03:28:57] <andypugh> But most likely a glitch and anti-glitch, the spike lasts 14mS, and it has to have been counted up and down in encoder counts to get as far as the halscope screen.
[03:30:50] <andypugh> Anyway, it is extremely late here.
[03:32:44] <andypugh> http://www.pastebin.ca/2003463
[03:33:26] <andypugh> Is all the code. (And yes, in the real version "B" is "Accum" because that is what it started as, and I re-used it.
[03:35:05] <andypugh> See you all tomorrow, I expect.
[03:35:11] <cradek> goodnight!
[04:28:16] <skunkworks> added a lowpass filter to the spindle speed for readouts and at speed. pretty cool! (just looked at the lowpass comp for pointers)
[04:30:29] <skunkworks> (added to the gearshift comp)
[11:49:53] <jthornton> cradek: thanks, I got called away from the computer...
[14:27:55] <dgarr> cradek: truetype-tracer V4 returns status=99 when sole option is -? because there is no break in switch statement -- is that intentional? would you consider a patch that adds a -v option for version so using scripts can test version?
[14:28:02] <dgarr> http://www.panix.com/~dgarrett/stuff/ttt.diff
[17:33:28] <psha> cradek: may i kindly ask you to make a screenshot of touchy + gladevcp panel?
[17:33:41] <psha> or you are not using it?
[18:41:29] <cradek> dgarr: I can't get your patch to apply - would you recreate it with -u or -c?
[18:41:31] <cradek> chris@rover2:~/projects/truetype-tracer$ patch <ttt.diff
[18:41:31] <cradek> patch: **** Only garbage was found in the patch input.
[18:41:31] <cradek> psha: sorry, I'm not using it right now - I never finished my panel for the lathe.
[18:41:32] <psha_> i've seen it, thanks )
[18:41:32] <psha_> i've created screenshot with example panel
[18:42:47] <mhaberler_> mhaberler_ is now known as mhaberler
[18:43:19] <cradek> dgarr: forget it - your version must be very different from mine - I am fixing those two things manually
[18:44:12] <psha> !@#$@!! another split
[18:44:47] <psha_> psha_ is now known as psha
[18:45:42] <cradek> dgarr: done, thanks
[18:50:49] <morfic-> morfic- is now known as morfic
[20:02:11] <cradek> psha: good question about setting flags. I think it is assumed that it will take many servo cycles to stop - usually that is true - but for my programs sometimes I probe very slowly - machine accel is high - it might be possible to just stop right away
[20:02:56] <psha> when movement after probe is stopped in the middle - is it telling you something?
[20:02:59] <psha> about probe for example?
[20:03:08] <cradek> no error is shown
[20:03:28] <cradek> I will go to the shop now and try to find a pattern
[20:03:52] <psha> is it possible that interp is rescheduled before probe flags are set?
[20:04:27] <cradek> I don't really know how it works
[20:07:21] <cradek> hm, it is the time of year when the shop is not very warm :-/
[20:09:35] <mshaver> Anyone know (or care to guess) why sometimes I can 'loadrt hm2_pci config="firmware=hm2/5i20/sssvst2_2_2.bit num_encoders=1 num_pwmgens=1 num_stepgens=4 conf_sserial=0x00000001"' sucessfully, and other times I get 'insmod: error inserting '/usr/realtime-2.6.32-122-rtai/modules/emc2/hm2_pci.ko': -1 Invalid parameters'. dmesg says:[ 875.099217] hm2/hm2_5i20.0: hm2_sserial_waitfor: Timeout (751mS) waiting for addr 5b00 &mask ffffffff va
[20:09:35] <mshaver> [ 875.099225] hm2/hm2_5i20.0: DATA addr 5c00 after timeout: 0
[20:09:35] <mshaver> [ 875.099229] hm2/hm2_5i20.0: failed to parse Module Descriptor 5
[20:09:35] <mshaver> [ 875.099238] hm2_5i20.0: board fails HM2 registration
[20:10:00] <mshaver> oops. meant to format that better
[20:18:49] <cradek> psha: I have not yet seen it fail :-(
[20:21:07] <mhaberler> we're disappointed
[20:23:22] <cradek> works perfectly today
[20:23:26] <cradek> dangit
[20:26:47] <pcw_home> mshaver: did the 8I20 actually not start when it fails? (red fault light on, no blinking green status)
[20:27:20] <mshaver> hmm, hold on...
[20:30:38] <psha> cradek: :))
[20:32:47] <cradek> saw it fail once
[20:33:01] <psha> on the move or on probe?
[20:33:17] <cradek> last move of program, after the probe I think
[20:33:26] <cradek> I think it stopped the move early
[20:33:57] <cradek> I think the program continued though, because it printed the final message
[20:35:58] <psha> maybe i've forgot to add some synch
[20:36:58] <cradek> I think it is getting an error but not stopping
[20:37:10] <mshaver> pcw_home: Now it's working :( Sometimes I get the blinking green status, sometimes not.
[20:37:36] <cradek> if I take the probe out of the hole and run probe-hole routine, and then poke probe randomly with my finger, it will report "probe tripped during non-probing move" but then keep moving forever (!!)
[20:38:26] <cradek> maybe it is getting a bounce and not handling the error correctly
[20:38:32] <cradek> oops - not forever - only to end of move
[20:39:01] <psha> tripped ruing non-probing...
[20:40:12] <cradek> also was able to get 'probe tripped during non-probe mdi command' but then it kept moving
[20:40:21] <cradek> maybe it is not your changes at all??
[20:41:02] <psha> if it's working in auto mode and not working in MDI mode - that's my changes i think
[20:41:25] <cradek> wait a sec
[20:41:38] <cradek> when in auto mode, it looks like it ignores extra trips during G0 move
[20:41:52] <cradek> I bet it is bouncing - extra trips during auto/mdi are handled differently
[20:43:28] <cradek> // running an MDI command
[20:43:36] <cradek> ^ see this in control.c
[20:44:37] <cradek> if in mdi and there is a probe bounce, it aborts that move then blindly continues
[20:44:51] <andypugh> mshaver: I had a bug in the stop/run handshaking code, but the initialisation always works for me. It might be a difference between the firmwares.
[20:45:02] <cradek> I don't think it is your code.
[20:45:27] <psha> what is probe bounce? what it's not tripped?
[20:45:46] <psha> last what has to be 'when' :)
[20:45:53] <mshaver> I've been poking around and when I remove 'setp hm2_5i20.0.watchdog.timeout_ns 10000000' from the hal file, I get a blinking status light and things seem to work correctly.
[20:45:57] <cradek> yes - an extra unwanted rising edge of the probe signal
[20:46:36] <cradek> I bet at control.c:402 there should be SET_MOTION_ERROR_FLAG(1)
[20:46:37] <andypugh> mshaver: Interesting.
[20:46:55] <andypugh> Is it a slow or a fast blinking status light?
[20:47:09] <mshaver> about 1Hz
[20:47:16] <andypugh> That's good
[20:47:27] <mshaver> is that fast or slow
[20:47:50] <andypugh> That's slow. Fast is much faster.
[20:47:51] <psha> cradek: but the question why auto and mdi modes works so different still exists...
[20:48:23] <cradek> it is on purpose
[20:48:29] <cradek> see line 398
[20:48:54] <psha> yes
[20:48:55] <cradek> mdi command is more likely to be wrong and break the probe
[20:49:02] <psha> 398 tpGetExecId(&emcmotDebug->queue) <= 0) {
[20:49:04] <psha> ?
[20:49:09] <cradek> in auto mode this error (extra bounce from probe) is ignored on purpose
[20:49:11] <cradek> yes
[20:49:15] <cradek> mdi motion ids are negative
[20:49:21] <psha> ah
[20:49:22] <cradek> auto motion ids are positive
[20:49:45] <psha> yes, i've noticed that
[20:49:50] <cradek> bug is no MOTION_ERROR_FLAG
[20:49:58] <cradek> maybe bad feature is auto/mdi being treated differently here
[20:50:10] <mshaver> So, I'll continue poking around with this! I compile bldc.comp & it loads and has the expected pins, so I just need to learn how to use it. My application is a spindle, so it's a little different from what you were doing, luckily simpler.
[20:51:39] <cradek> I will add MOTION_ERROR_FLAG and test
[20:51:51] <psha> cool
[20:53:48] <cradek> building on the mill takes a while :-)
[20:54:20] <psha> :)
[20:55:20] <cradek> yay, this makes me happy
[20:55:23] <cradek> I really want this to work
[20:58:11] <pcw_home> mshaver: does a longer timeout work? (blink should be ~1Hz for 1KHz update rate (blink is com rate /1024 IICRC)
[20:58:43] <pcw_home> (longer watchdog timeout)
[20:58:47] <andypugh> mshaver: You could just run bldc in the dumb vfd mode, but that will use a lot more current and get very hot.
[20:58:56] <mshaver> I'll try that...
[20:59:16] <andypugh> I think you will need a PID controller looking at encoder velocity really.
[20:59:34] <mshaver> andypugh: better not - no heatsink!
[20:59:51] <andypugh> Then current will go to zero any time the spindle is running at full speed
[21:00:08] <andypugh> I am more concerned about the motor than the 8i20 in VFD mode
[21:00:19] <mshaver> yep, that's what I have in mind - pid
[21:00:34] <pcw_home> 7.5 A no heatsink is OK for quite a while (30A not so much)
[21:01:24] <andypugh> In that hal file I sent it should just be a case of pid.input being spindle speed request, and pid.feedback being encoder velocity.
[21:03:00] <mshaver> pcw_home: previous timeout X 100 seems to work
[21:03:00] <andypugh> You can fiddle the spindle speed output to match the encoder velocity by lying about the encoder scale to the encoder module, as bldc uses its own scale and works on rawcounts.
[21:03:57] <pcw_home> But that's (1 S) a long time to be crashed ans still moving motors...
[21:04:13] <andypugh> pcw_home: Ah! Just the man. sserial register 0 clearly writes to the digital outputs of the 7i43, do reads from there read the inputs, and the analogue channels are on register 1?
[21:04:31] <mshaver> I'll see what .1 seconds does...
[21:04:44] <pcw_home> Yep
[21:05:34] <andypugh> Should have a 7i64 driver by midnight then :-)
[21:06:00] <pcw_home> two channels 16 bits each in high and low half
[21:06:48] <pcw_home> I will add 7I64 SSLBP stuff to 7I64 manual later this week but its really simple
[21:07:59] <pcw_home> 7I66 (lower cost common switched power version of 7I64) and 7I72 (pendant interface) are similar
[21:08:56] <andypugh> 7i72 might make aram very happy.
[21:09:37] <andypugh> (Have you ever looked at the Concept Machinery website?)
[21:11:29] <cradek> psha: still building...
[21:11:43] <pcw_home> It has the advantage of using RS-422 so 100 feet or so is no problem
[21:11:45] <pcw_home> I think I have looked at it (We made some Advanced Motion drive? breakout cards one time for Aram so he would quit calling)
[21:12:22] <andypugh> He seems to spend a lot of money for questionable results. I guess that suits suppliers.
[21:12:36] <pcw_home> Well....
[21:14:58] <andypugh> Actually, his new big machine looks fairly serious.
http://www.conceptmachinery.com/
[21:18:34] <pcw_home> Ah thats right the breakout we made was for Servo Dynamics...
[21:19:02] <pcw_home> BBIAB hay run
[21:31:54] <cradek> psha: I think that fixes it!
[21:31:58] <cradek> psha: sorry for the wild goose chase
[21:33:14] <andypugh> can I be confident that a HAL "bit" is 1, and that b |= (halbitpin << n) will have the effect I anticipate?
[21:33:26] <cradek> no
[21:33:36] <mhaberler> cradek: you mean to say oword call in mdi mode with probe in sub now works?
[21:33:48] <cradek> mhaberler: yes
[21:33:52] <psha> cradek: cool
[21:34:04] <cradek> I will push the fix shortly
[21:34:14] <mhaberler> cradek,psha: muchos kudos! this is wildly appreciated
[21:34:14] <andypugh> cradek: well, 0 was asumed possible too
[21:34:27] <cradek> andypugh: when in doubt, !!halbitpin
[21:35:07] <psha> andypugh: better 4, for sure
[21:35:07] <andypugh> So safer to use if (halbitpin) b |= (1 << n)
[21:35:23] <cradek> andypugh: yes exactly
[21:35:35] <psha> cradek: at least it's fixed now :)
[21:36:00] <cradek> psha: I have to decide whether that auto/mdi error detection difference is good or bad
[21:36:39] <andypugh> OK. I never trust "true" to be 1, anyway as the first computer I used used true = FF (it was an 8 bit computer)
[21:46:51] <psha> cradek: that's up to you :) i'm focused on video/gladevcp now
[21:53:45] <CIA-8> EMC: 03cradek 07master * r8c72345f9d65 10/src/emc/motion/control.c: Abort subsequent motions after a certain type of probe error
[21:53:51] <CIA-8> EMC: 03cradek 07master * r40dc95e48118 10/src/emc/motion/control.c: Set flags before aborting motion
[23:13:01] <skunkworks> so - I have mdi commands as pins in the ini (ie MDI_COMMAND = G0 X0 Y0 Z0) I was firing them from ladder today but not consistantly. Seems you need to set the pin high for a undetermined amount of time. Is there a better way? I just added a second on time delay to fix the problem.
[23:14:02] <andypugh> skunkworks: I guess MDI_COMMAND is spotted by a userspace component.
[23:14:32] <cradek> yes halui is userland and it just polls its input pins when it gets around to it
[23:14:41] <skunkworks> ah - so maybe a time delay is the only option.
[23:14:56] <andypugh> Perhaps you need to handshake, ie have the MDI_COMMAND routine set a bit low with a G65 to say "OK, I hear you"
[23:15:28] <cradek> in an alternate universe, halui could use IO pins, and push the pin back low when it got the message
[23:15:33] <andypugh> MDI_COMMAND = O<my_subroutine> CALL works, you know :-)
[23:15:37] <cradek> that's what IO pins are for
[23:16:08] <skunkworks> hmm - interesting.
[23:17:12] <mhaberler> cradek: thanks - that fix is a real gamechanger in terms of extensibility
[23:17:21] <andypugh> I have MDI commands that call subroutines that read Pyvcp panel boxes and perform complete machining operatios.
[23:17:43] <mhaberler> andypugh: since tonight?
[23:17:54] <andypugh> No, been that wa y for ages.
[23:18:11] <andypugh> Why, was it meant to not work?
[23:18:22] <mhaberler> andypugh: then not subs with probeing I guess
[23:18:29] <andypugh> No.
[23:18:54] <mhaberler> andypough: your were safe by not pushing the envelope
[23:19:15] <andypugh> Damn! Must try harder
[23:20:16] <psha> andypugh: anything triggering wait in code was not working
[23:20:20] <skunkworks> cradek: when you say - alternate universe - do you mean that it isn't something that is done yet?
[23:20:28] <skunkworks> *isn't
[23:20:29] <psha> probing, some M66 reads etc
[23:21:30] <andypugh> Ah, that is intersting, as I seem to be getting interested in auto tool-probe on toolchange.
[23:22:55] <skunkworks> wow - my sentence didn't make much sense.
[23:23:19] <psha> skunkworks: there are two ways to report back that code is done
[23:23:42] <psha> first - add g-code in the end of your commands
[23:24:17] <psha> second - add halui.mdi-commaid-XX-done pin and set it high when commands is receieved/done
[23:24:29] <psha> first is far more reliable :)
[23:24:57] <psha> halui is userspace comp with 100ms sleeps between updates
[23:25:34] <psha> but that 100ms may be extended with some additional waits (e.g when submitting EMC commands)
[23:28:56] <skunkworks> so - if at the end of the <my_subroutine> I set a hal bit true.... Now how do I set it false again. seems like a vicious circle....
[23:29:32] <psha> dunno :)
[23:29:46] <andypugh> Good question
[23:29:50] <cradek> skunkworks: what are you trying to do exactly?
[23:29:52] <skunkworks> can I set it false through hal?
[23:29:57] <jthornton> skunkworks: what are you working on
[23:30:07] <jthornton> cradek: thanks for fixing my comp
[23:30:14] <cradek> jthornton: np
[23:30:26] <skunkworks> the pallet change sequence needs to make sure that the machine is in the right location for each pallet.
[23:30:27] <andypugh> That would work, use an edge-detector function in HAL
[23:30:28] <cradek> jthornton: thank jeff for saying what the fix was...
[23:30:50] <jthornton> it is a team effort for sure
[23:31:02] <skunkworks> for one pallet it needs to be X38Z25B180
[23:31:09] <andypugh> Did the formatting get fixed?
[23:31:17] <skunkworks> for the other it needs to be X0Z25B180
[23:31:19] <andypugh> (Sorry to be picky)
[23:31:21] <jthornton> I don't know but I'll check
[23:31:36] <cradek> no, I didn't pretty it up
[23:31:42] <cradek> skunkworks: ew
[23:31:53] <andypugh> I think the HAL example code needs a leading space on each line
[23:32:03] <skunkworks> heh
[23:32:35] <andypugh> skunkworks: Or the pallets land on the floor?
[23:32:41] <skunkworks> yes.
[23:33:17] <skunkworks> there are a lot of safety though. there are limit switches that activate when the machine is in the right place.
[23:33:51] <skunkworks> hmm - I could activate the the mdi call until the in-position goes false...
[23:33:59] <jthornton> I fixed the formating
[23:34:10] <skunkworks> but that doesn't work if the machine is already there.
[23:34:21] <skunkworks> I am sure there is about 1000 ways to do this.
[23:35:05] <andypugh> Talking of comps, a chap has extended the gearchange comp to 3 gears. It seems to me that it ought to be a personality switch, and arbitrary.
[23:35:51] <skunkworks> just going by my gear shift comp - I don't think there can really be a standard 1-16 gears... or such
[23:35:53] <andypugh> Is it worth me re-jigging it?
[23:36:01] <jthornton> that does make sense
[23:36:02] <CIA-8> EMC: 03jthornton 07master * r55cfb95d257b 10/src/hal/components/time.comp: fix html formatting
[23:37:19] <dgarr> cradek: i made a diff -u but i'm not sure you need it now?
http://www.panix.com/~dgarrett/stuff/ttt.diff.u
[23:37:27] <andypugh> Well, I was thinking 1-32 gears and the choice of u32 gear_numeber and/or a bit for each.
[23:37:37] <cradek> sorry I should have been clearer - I already applied the changes
[23:37:49] <cradek> thanks
[23:37:51] <dgarr> oh -- will there be a new tar file?
[23:40:48] <cradek> ugh I have truetype-tracer in two git repositories
[23:40:57] <cradek> looks like one is 3.1 and one is 4.0
[23:41:18] <jthornton> no wonder I'm confused :)
[23:44:32] <skunkworks> well - I can get it working with the delay. not a big deal and 'tweek' it later.
[23:46:18] <jthornton> so in the HAL manual 6.5 Per-instance data storage CTYPE is a simple one-word C type, such as float, u32, s32, int, etc. this is wrong and should be __u32 and __s32?
[23:46:31] <cradek> dgarr: applied in the right place now - thanks
[23:51:34] <andypugh> jthornton: I think you can use anything in that part, it translates verbatim into the C code.
[23:51:53] <andypugh> But really I think you need a pronouncement from jepler.
[23:54:15] <dgarr> cradek: i'm confused, is there a new tar file on timeguy.com or maybe it takes a while to update?
[23:54:48] <andypugh> Hmm, looking at my comps I have used int, char, signed. I recant my earlier statement and emphasise the later.
[23:55:39] <cradek> unfortunately there's nothing that makes automatic releases or anything like that - when the changes build up to something meaningful I build a deb and post that and the tarfile on my site (and often put it on the linuxcnc cd and/or git repository)
[23:56:04] <cradek> I am bad at automating things
[23:56:46] <dgarr> ok - thanks
[23:58:55] <mshaver> andypugh: so, I've gotten to the point where I can init the motor
[23:59:33] <andypugh> It does the alignment sequence?
[23:59:44] <mshaver> the motor has a holding torque and there are 7 stable positions