Back
[00:00:07] <andypugh> 7?
[00:00:31] <mshaver> yes I get bldc.0.init-done in response to bldc.0.init
[00:00:33] <andypugh> OK, you seem to have a 14 pole motor.
[00:00:38] <mshaver> yes, 7
[00:00:58] <andypugh> Do you see the motor twitch when you init?
[00:01:15] <mshaver> very slight
[00:01:33] <andypugh> It will be quite slight with a 14 pole motor
[00:01:48] <mshaver> , but if I disable hm2_5i20.0.8i20.0.0.amp_enable it goes loose
[00:02:13] <andypugh> That's good :-)
[00:02:48] <mshaver> my problem is: increasing the hm2_5i20.0.8i20.0.0.current increases the holding torque, but doesn't cause rotation
[00:02:58] <mshaver> of sourse I'm set to 6 poles
[00:03:02] <mshaver> course
[00:03:26] <andypugh> You definitely need 14 as the poles parameter
[00:04:15] <andypugh> Then it might work. If it doesn't try a negative number in the scale parameter
[00:04:53] <andypugh> Just to really confuse matters, you might also need to negate the PID Pgain.
[00:05:05] <mshaver> now i have 11 positions!
[00:05:19] <mshaver> with poles=14
[00:06:11] <andypugh> Ah
[00:06:49] <andypugh> There is probably something curious happening
[00:06:57] <andypugh> Is the PID active?
[00:07:23] <mshaver> yes, "net init-done bldc.0.init-done pid.0.enable 8i20.done"
[00:07:41] <mshaver> kill that for now?
[00:08:22] <andypugh> Yes. In fact to count poles, set the cfg=n in the loadrt line and comment out anything else bldc-related
[00:08:48] <mshaver> doing...
[00:08:57] <andypugh> Then restart
[00:09:15] <andypugh> (Not the PC, just Axis or HAL)
[00:09:27] <andypugh> Are you in Axis or Halrun or something else?
[00:10:00] <mshaver> I'm sourcing a script in halrun - want me to pastebin it?
[00:10:26] <andypugh> That's the simplest way
[00:10:42] <andypugh> OK, so, source your reduced script
[00:11:23] <andypugh> show pin bldc* should show you a frequency pin?
[00:12:43] <mshaver> http://www.pastebin.ca/2004228
[00:17:13] <andypugh> I think you might need to comment out everything except the loadrt and addf lines. What I am proposing is to run in dumb vfd mode at a tiny current to count the motor poles
[00:19:37] <mshaver> ok, because with everything commented out I get no pole detents
[00:20:08] <mshaver> let me see if I can enable the drive and dial in a little current in "n" mode
[00:21:33] <andypugh> Actually, commenting out everything was perhaps a little too much. I think you still want the links between angle and current on bldc and 8i20.
[00:21:48] <andypugh> However, what you have now will work
[00:22:21] <andypugh> setp hm2_5i20.0.8i20.0.0.current 0.1
[00:22:36] <andypugh> setp hm2_5i20.0.8i20.0.0.angle 0
[00:23:02] <andypugh> setp hm2_5i20.0.8i20.0.0.enable 1
[00:23:22] <mshaver> I did all but the angle and get 4 poles
[00:23:35] <andypugh> 4 "detentes"?
[00:23:36] <mshaver> or 4 positions
[00:23:43] <mshaver> yes
[00:23:46] <andypugh> That's an 8 pole motor then.
[00:24:01] <mshaver> ok, restoring the other stuff to try again!
[00:24:28] <andypugh> So, set poles to 8, and uncomment the angle, enable and current links. Leave the rest out for the time being
[00:28:00] <mshaver> ok, now I have 8 detents with poles=8
[00:29:11] <mshaver> http://pastebin.ca/2004237 - current 8i20.hal
[00:31:05] <mshaver> initing the motor causes a small jog, maybe 30 degrees, then a return to the starting point and it's done
[00:32:32] <andypugh> What do you get if you setp pid.0.in to 1?
[00:33:58] <andypugh> then try switching the signs of bldc.0.scale and pid.0.Pgain
[00:36:20] <mshaver> well, I have setp pid.0.maxoutput 1, so pid.0.output is limited to between 1 and -1 for any pid.0.command - is that what we want?
[00:36:48] <andypugh> Yes, that sets the 8i20 driver to max or reverse max
[00:36:55] <andypugh> http://pastebin.ca/2004242
[00:37:04] <mshaver> what I get is (perceptibly) larger holding torque and more audible squeal
[00:37:07] <andypugh> Ought to at least make the motor spin
[00:39:20] <mshaver> loading your pastebinned file
[00:39:36] <mshaver> had to comment out setp bldc.0.scale 2000 in "n mode"
[00:39:46] <andypugh> Ah, yes
[00:40:38] <andypugh> And probably poles too.
[00:40:57] <andypugh> And initvalue.
[00:41:37] <andypugh> (Sorry)
[00:43:30] <andypugh> in fact:
http://pastebin.ca/2004246]
[00:46:46] <mshaver> OK, in "n mode" I have 4 detents
[00:47:44] <andypugh> what happens if you setp frequency?
[00:48:39] <andypugh> I went too far, need to uncomment line 33 :-)
[00:49:19] <mshaver> ok, looking at this...
[00:50:46] <andypugh> You know what I don't see? net bldc.0.out hm2_5i20.0.8i20.0.0.current
[00:51:14] <andypugh> I might be missing it, but I don;t think you have a current input to the 8i20
[00:51:45] <mshaver> I changed frequency (was 4) to 10 - no change
[00:52:29] <andypugh> setp hm2_5i20.0.8i20.0.0.current 1
[00:53:39] <andypugh> (Or net it to bldc, and set bldc.value)
[00:55:12] <mshaver> changing the current changes the holding torque
[00:55:45] <mshaver> what does frequency do?
[00:55:46] <andypugh> loadusr halmeter
[00:55:50] <mshaver> ok
[00:56:10] <andypugh> Can you see bldc.0.rotor-angle changing?
[00:56:11] <mshaver> what to look at?
[00:57:37] <andypugh> If you set the frequency to (say) 0.5 you should see the rotor angle moving between 0 and 1 every 2 seconds,
[00:57:43] <mshaver> yes, it is creeping in a positive direction about .1 every 10 seconds
[00:58:49] <mshaver> yep, at .5 it is incrementing much faster
[00:59:11] <mshaver> the motor shaft is stationary through
[01:03:16] <andypugh> That's 2 wierd things then
[01:04:12] <andypugh> The rotor angle should be moving smoothly between 0 and 1, then instantly back to 0, and then up again.
[01:04:28] <andypugh> And the motor really should be following
[01:04:47] <mshaver> that's what the number is doing
[01:05:03] <mshaver> but not the motor
[01:05:42] <andypugh> No, PID, and rotor_angle netted directly to the 8i20 angle input?
[01:06:02] <andypugh> Can you put the halmeter on 8i20 angle and 8i20 current?
[01:07:06] <mshaver> 8i20 angle is a constant 0, current is .5
[01:07:59] <andypugh> Aha!
[01:08:18] <andypugh> Looks like a flaw in the HAL wiring then
[01:08:24] <mshaver> #net angle hm2_5i20.0.8i20.0.0.angle bldc.0.rotor-angle
[01:08:40] <mshaver> this is commented out in the file i'm currently running
[01:09:00] <andypugh> I suggest quickly entering it at the command promot
[01:09:45] <mshaver> and the shaft turns!
[01:10:12] <andypugh> I am doing this bit for 2 reasons, firstly to get a definite pole count, and secondly so you can at least see the motor spin
[01:10:34] <mshaver> it's impressive!
[01:10:37] <andypugh> setp frequency to 1 and see how many seconds per turn, I guess 8
[01:10:58] <andypugh> then setp 50 and watch it jump off the table
[01:12:46] <mshaver> at freq=1 1 rot is about 5 secs
[01:13:03] <mshaver> it's a little jerky
[01:14:28] <mshaver> at freq=5 it's a little less than 1 rpm
[01:14:47] <andypugh> rps?
[01:14:47] <mshaver> at freq=10 the shaft rocks back and forth in one place
[01:14:56] <mshaver> sorry, rps yes
[01:15:02] <andypugh> What voltage
[01:15:37] <mshaver> 156
[01:15:42] <andypugh> Hmm.
[01:16:05] <andypugh> servo thread period?
[01:16:11] <mshaver> it's meant for 220vac rectified, plus we have the current limited
[01:16:31] <mshaver> servo_period_nsec=1000000
[01:16:46] <andypugh> Try a little more current, but be careful as this mode is inefficient
[01:17:31] <andypugh> In fact, the poor performance might be because we are in dumb VFD mode
[01:19:13] <mshaver> ok, at current=2 i could get to freq=20
[01:19:27] <mshaver> the leap to freq=50 didn't work
[01:20:44] <andypugh> Time to go to proper commutation I think
[01:21:18] <mshaver> i can get to 50 by 5's
[01:21:25] <mshaver> ok
[01:22:05] <andypugh> Go to type q, put in the PID, make sure the bldc.0.out to 8i20 current link is there, and see how that goes.
[01:27:44] <mshaver> should bldc.0.out be tied to current or frequency?
[01:28:32] <andypugh> current
[01:28:58] <andypugh> In any mode with a feedback you don't have the frequency pin.
[01:36:47] <mshaver> just taking the time to fix up and save this working example...
[01:37:34] <pcw_home> If you get a squeel when the angle and torque are constant, you may need to detune the current loop somewhat
[01:39:30] <andypugh> I am not sure we have a way to do that at the moment
[01:40:03] <andypugh> (Unless you mean the EMC2 PID loop)
[01:42:40] <mshaver> I wonder why I _have_ to load trivkins?
[01:42:48] <pcw_home> You should just get noise (like white noise) from Hall sensors
[01:42:50] <pcw_home> Heres how we dot it with a batch file where %1 is KP and %2 id KI
[01:42:51] <pcw_home> wpd kqp %1
[01:42:53] <pcw_home> wpd kdp %1
[01:42:54] <pcw_home> wpd kqi %2
[01:42:56] <pcw_home> wpd kdi %2
[01:44:07] <mshaver> btw, this drive works really well, even in vfd mode
[01:45:28] <andypugh> (don't tell Pete we are using VFD, it's all direct-field)
[01:45:55] <pcw_home> It really cant work well in VFD mode until we have voltage mode supported
[01:47:55] <pcw_home> Its constant current now like a step motor (if you dont have the rotor alignment and encoder feedback working)
[01:48:01] <mshaver> I guess what I mean is: Compared to the Chinese brushless motor drives we are currently using, this one has the ability to be tweaked to perform well. It's not a "take it or leave it" deal.
[01:50:35] <pcw_home> Do put a plastic shield around the 8I20 when testing, we have blown up two (firmware bugs on one and driving a 120V desk lamp from 360V as brake on the other)
[01:51:41] <andypugh> Now you tell me! So on the living room carpet under the TV is not the best place?
[01:52:45] <pcw_home> Well, how many Joules do your PS caps store? Quite a bang is possible
[01:55:00] <pcw_home> We did find the 120V bulbs quickly become shorts at 360 VDC
[01:55:29] <andypugh> I have 1uF @ 70V (a lot less scary than the 2uF @ 700V my other motor drive had)
[01:55:52] <andypugh> You should use proper 240V bulbs
[01:58:00] <pcw_home> Well we we using the lamp when experimenting with the brake at low voltage (very visible)
[01:58:01] <pcw_home> but forgot that is was still across the brake resistor when we did a full voltage test...
[01:58:32] <andypugh> I am surprised it became a short, not OC
[01:58:36] <tom3p> how do i git v2.4.6? i have v2.5.0-pre0
[01:58:39] <andypugh> However, back to business
[01:59:02] <andypugh> tom3p: 2.5 is better :-)
[01:59:16] <tom3p> ok, i have faith :)
[01:59:57] <pcw_home> Short long enough to blow up the 8I20 (we had 900 uF of filter at 360V)
[02:00:39] <andypugh> pcw_home: Just as a very simple loopback test to check the 7i64 input pins, is there a handy 5v anywhere on the board when it is cat5 powered?
[02:02:28] <pcw_home> Yes the 5V power terminals can be used (all 5Vs are common)
[02:02:29] <andypugh> I was going to try 5V O1+ O1- I1+ I1- GND
[02:04:09] <andypugh> 7i64 would have saved skunkworks a lot of relay cards, I think
[02:06:30] <pcw_home> I think he has some AC ins and outs so for that IO module racks may be a better choice
[02:09:15] <pcw_home> We do a loopback to test the 7I64s (24X 10 Ohm loads with 24V looped back to the inputs) rotating 'on' test
[02:09:17] <pcw_home> (since we dont have enough current to power all 2.4A loads at once)
[02:14:10] <andypugh> Couldn't you just wire them all in series with each other and one load?
[02:14:47] <andypugh> Or is that what you mean
[02:15:38] <andypugh> Does the general class GPIO include analogue?
[02:16:09] <andypugh> I am trying to decide how to name the analogue inputs.
[02:16:56] <pcw_home> The drop for all in series might turn on in input
[02:17:27] <andypugh> (To save linguistic friction I prefer to avoid using the word "analogue" or "analog")
[02:19:20] <andypugh> Abbreviating to "anal" seems like a poor plan.
[02:20:04] <andypugh> You know, I am not sure this question has arisen before, is this the first analogue input pin into a HAL driver
[02:22:01] <mshaver> motion has analog inputs
[02:22:18] <mshaver> it's not really a driver though
[02:31:42] <mshaver> So, I'm back where I started I think. My current hal and pyvcp xml files are
http://pastebin.ca/2004293 - When I dial in some input to pid.0.command, the pid.0.output, bldc.0.value, bldc.0.out, and hm2_5i20.0.8i20.0.0.current pins follow in lock step until 1.0 (or -1.0). I get 6 encoder counts or movement and 0.016 (+ or -) of rotor angle, and that's all.
[02:32:46] <andypugh> negate the encoder scale
[02:32:54] <mshaver> ok!
[02:33:01] <andypugh> And/or the pid.Pgain
[02:34:45] <andypugh> Electrical phase needs to "run away" from the rotor, and if the rotation sense of the rotor and encoder is different then they converge instead.
[02:39:13] <andypugh> Right, that's 7i64 working in all senses.
[02:39:50] <mshaver> I tried all 4 permutations of hm2_5i20.0.encoder.00.scale and Pgain - same basic results
[02:39:52] <andypugh> 3 days hardware to driver, I call that a good service :-)
[02:41:09] <mshaver> did you mean bldc.0.scale?
[02:41:14] <andypugh> mshaver: Err, sorry, I was unclear. Not _that_ encoder scale. The bldc.scale
[02:41:21] <andypugh> Yes.
[02:41:24] <mshaver> OK!
[02:41:32] <mshaver> doing...
[02:42:54] <tom3p> i tried 2.4.6 and got "emcsvr: symbol lookup error: emcsvr: undefined symbol: _ZN15RCS_CMD_CHANNELC1EPFilPvP3CMSEPKcS6_S6_i"
[02:42:54] <tom3p> then tried to go back to 2.5.0~pre, same message
[02:43:10] <tom3p> do i need to wipe the dir ( i got a b/u)
[02:44:31] <tom3p> same message on any of several startup menu choices
[02:47:04] <andypugh> tom3p: Try a restart?
[02:47:39] <andypugh> lsmod might be interesting, I suspect you might have orphan rtai modules loaded
[02:48:37] <tom3p> lsmod shows no rt-blah, no emc-blah
[02:49:05] <andypugh> I guessed wrongly then
[02:49:10] <tom3p> what do you mean by 'restart'? restart linux?
[02:49:17] <andypugh> 'fraid so
[02:49:24] <tom3p> ok
[02:50:22] <tom3p> thanks bbl
[02:50:29] <andypugh> It is the only way I know to unload stuck modules, though the evidence seems to point away from that being the problem
[02:55:34] <mshaver> OK, so it runs and I can control the speed up to a point, but only in one direction.
[02:56:09] <andypugh> You want both directions!
[02:56:09] <mshaver> it won't go the other way
[02:56:19] <mshaver> well, I had hoped
[02:56:27] <andypugh> I might have fixed that
[02:56:42] <andypugh> But I didn't know it was broken.
[02:56:42] <mshaver> <laughing>
[02:57:20] <andypugh> I put in an absolute-out for a specific kind of drive.
[02:57:32] <mshaver> it also doesn't get up to the max speed
[02:57:44] <mshaver> so, I need a new bldc.comp?
[02:58:35] <andypugh> I am not sure, it all gets very confusing, as if you are not careful you flip the phase by 180 degrees and reverse the current at the same time, and end up going the same way.
[02:59:01] <andypugh> A negative current into the 8i20 should reverse the motor
[02:59:19] <mshaver> on accelerating, I have some "rough spots" as I go up in velocity
[02:59:33] <andypugh> How are you trying to reverse the motor?
[03:00:09] <mshaver> I have a pyvcp dial that is tied to pid.0.command - it's a float
[03:00:42] <andypugh> do negative inputs give negative currents to the 8i20?
[03:01:00] <andypugh> (and if not, is it the bldc comp that flips them?
[03:01:05] <mshaver> hmm, I think, let me look
[03:01:56] <andypugh> Any idea how fast you are getting?
[03:03:48] <mshaver> when I go in the minus direction, everything is minus (pid.0.output, bldc.0.value, bldc.0.out, and hm2_5i20.0.8i20.0.0.current), in the plus dir it's all plus
[03:04:11] <mshaver> I can only go minus, probably a few hundred rpms max
[03:04:40] <pcw_home> Negative current gives torque in the opposite direction (angle for 8I20 is always just rotor position)
[03:04:47] <mshaver> sometimes I have to give the shaft a spin to get it started
[03:05:20] <andypugh> I think that the homing is not working right
[03:05:36] <pcw_home> (was going to say as much)
[03:06:13] <andypugh> It's probably worth working out what the encoder offset it.
[03:07:16] <pcw_home> Are you using 7.5 A to align the rotor to start?
[03:07:57] <andypugh> I think he is using 0.2A.
[03:08:12] <pcw_home> Well that wont work...
[03:08:15] <mshaver> I have "setp hm2_5i20.0.8i20.0.0.max_current 7.5"
[03:08:30] <andypugh> (Sorry, that would be (0.2 * 7.5A)
[03:08:53] <mshaver> This is a 1kW motor
[03:08:56] <andypugh> But still, try bldc.initvalue 1
[03:09:38] <mshaver> doing...
[03:10:10] <pcw_home> asymmetrical operation (forward and reverse not equal) almost guarantees that the rotor alignment is not working
[03:13:12] <mshaver> big jump on init with that 1.0 initvalue
[03:13:24] <mshaver> no change in operation
[03:15:15] <andypugh> I would like to see it homing to index.
[03:15:29] <mshaver> andypugh: this is the same bldc.comp that I have
[03:15:39] <mshaver> I have an index pulse
[03:17:05] <andypugh> Are you sure it is the same bldc.comp? Not that I can recall when I last changed it.
[03:17:44] <andypugh> Anyway, they are not that different
[03:18:04] <mshaver> the new file has an extra CR at the end (I use meld for a GUI diff util - I highly recommend it)
[03:18:11] <andypugh> To find the index offset...
[03:18:50] <andypugh> Motor zero is one of the places where the motor sits with +V on A phase and -V on B and C phase.
[03:19:11] <andypugh> (Probably mark it with a pen)
[03:20:17] <andypugh> You then need to set encoder-latch and turn the shaft until the encoder counts zeros.
[03:21:16] <mshaver> Mine are U. V & W, but - do you mean get a dc supply and do this?
[03:21:35] <andypugh> Then turn the shaft back to the zero point. (I guess if you reversed that sequence you would not need the marker pen). The encoder offset for bldc is the counts shown by an index-zeroed encoder when the motor is at the zerp position.
[03:22:02] <mshaver> Suppose I was willing to hook up the Hall sensors?
[03:22:12] <andypugh> Yes, current-limited DC supply. (It's a pain, but the only way to be sure with semi-smart drives)
[03:22:23] <andypugh> That would be the best way.
[03:22:47] <mshaver> I think that's what I should do - Is that what you are doing?
[03:23:23] <andypugh> Having the halls wired lets you start at full torque from rest without any odd wiggles or funny sequences
[03:23:44] <andypugh> My motor has no Hall sensors.
[03:24:00] <mshaver> because they have a known alignment to the coils?
[03:24:13] <andypugh> Homing to index should be just as good, but needs work to determine offset.
[03:24:27] <mshaver> so you did the encoder offset procedure?
[03:24:41] <andypugh> No, my motor is a pain it has a resolver
[03:25:59] <andypugh> I am still trying to get it working properly. (I have used all the options with another smaller motor I have, with halls and encoder and index, so I have tested everyhting but only with one motor, and with an 7i39 not an 8i20)
[03:27:26] <mshaver> All the motors (I think) we're going to use will have Hall sensors - I think I'll just get my boss to send me a 7i37 board (or make a Hall to RS-422 board)
[03:28:01] <andypugh> You can probably wire the Halls direct to the 5i20. I do.
[03:28:29] <mshaver> true - for test purposes anyway
[03:29:12] <andypugh> You then have the fun of figuring out the hall pattern
[03:29:34] <andypugh> One test to try though, simplify things some more.
[03:29:46] <andypugh> comment out the PID
[03:30:02] <mshaver> I'm really happy with the results we got today. I think I'm going to stop and take the time to hook up the Hall sensors and proceed from there.
[03:30:08] <mshaver> ok, doing...
[03:31:09] <andypugh> Now set the bldc value to 1 and -1 and see how it runs.
[03:31:37] <andypugh> (And check you are seeing -1 or 1 at the 8i20 too)
[03:32:43] <andypugh> What's your 8i20 max current at the moment?
[03:36:39] <mshaver> I removed the pid and just hooked the pyvcp dial to bldc.0.value
[03:37:14] <mshaver> It takes off in the negative drection and runs jerkily (if at all) in the positive.
[03:37:30] <mshaver> current setting tracks the dial
[03:37:31] <andypugh> Most odd
[03:37:57] <mshaver> it's not oriented to the magnets - I think you all are right about that
[03:39:55] <mshaver> it would be nice if the drive could be programmed to supply the current to hold the motor in a home position, then emc could be used to figure out the encoder offset somehow
[03:40:51] <andypugh> I would be tempted to halscope the encoder angle during homing (triggering off of init). It ought to fly into lock, then rock +90, -90 and then back to 0 degrees. (or whatever that is in encoder counts)
[03:42:24] <andypugh> That is sort-of what the alignment does now. It flips the field around to find the rotor then moves it back and forth, then takes an encoder reading.
[03:42:51] <andypugh> It is entirely possible I have broken something.
[03:43:20] <mshaver> Once you knew the number of counts from the index position, is this ever necessary again?
[03:43:38] <mshaver> I could send you a motor
[03:44:01] <pcw_home> "it would be nice if the drive could be programmed to supply the current to hold the motor in a home position, then emc could be used to figure out the encoder offset somehow"
[03:44:02] <pcw_home> Thats supposed to be one of the startup modes
[03:44:29] <andypugh> Yes, that is the mode we are using now. Though it seems to not be working
[03:44:30] <pcw_home> ( and thats what we have done in testing)
[03:45:16] <andypugh> mshaver: You are in cfg=q ?
[03:45:37] <andypugh> mshaver: Sending a motor to the UK would be expensive.
[03:46:12] <mshaver> well, these machines come all the way from China to begin with, so...
[03:46:39] <mshaver> I know my boss Michelle is pretty jazzed about making this work, so who knows!
[03:47:15] <andypugh> You could try guessing the encoder offset, for fun.
[03:47:38] <mshaver> What this gives us is a 0- motor_max_rpm spindle drive with no belt changes
[03:48:34] <mshaver> is there a command that you could send to the drive that says, "snap the rotor to home ans stay there"
[03:48:35] <pcw_home> Well belt changes will give you more torque at low speeds and higher speed capability
[03:50:15] <andypugh> You know, I am not sure that we can home an 8i20 magnetically this way.....
[03:50:21] <pcw_home> yes just apply current with angle = 90 degrees (or -90 not sure off hand)
[03:50:39] <mshaver> true, but we'd have to redesign the head casting and get the Chinese to make a multi-pulley system, etc - we're hoping to improve on the current situation which is that you can stall the spindle motor with your hand at low speed
[03:51:15] <mshaver> the other problem is that the other drive they supply refuses to go less than 400 rpm
[03:51:26] <pcw_home> that (alignment method) works everytime for us
[03:51:56] <andypugh> mshaver: Ah! I know what is wrong!
[03:52:09] <pcw_home> If its a BLDC it should work fine as a servo with full torque at 0 speed
[03:52:27] <mshaver> Coriolis effect?
[03:52:46] <mshaver> yep, that's what I think re: BLDC
[03:52:47] <andypugh> you see that "drive-offset" parameter? It is there specially for the 8i20.
[03:53:02] <andypugh> But I forgot to actualy ever use it....
[03:53:35] <mshaver> mine is = 90
[03:53:52] <andypugh> Yes, but the internal calcs ignore it.
[03:54:22] <andypugh> Very sorry.
[03:54:49] <tom3p> andypugh, i had used the 'make install-menus' per
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Getting_the_source_with_git
[03:54:49] <tom3p> to fix... i did 'make clean' and followed same instructions SANS make install-menus and its ok now
[03:54:57] <mshaver> Oh, suuurre you are!
[03:55:31] <andypugh> Can I fix it tomorrow? 4am here, and it will need clear thought.
[03:56:12] <mshaver> Oh please do this tomorrow! It's 10:55pm here and I'm an old man.
[03:56:36] <mshaver> I want to go to bed and sleep for a while myself!
[03:56:44] <andypugh> Night all!
[03:56:53] <pcw_home> We will eventually allow setting 'D' current (no offset) in SSLBP but unforch needs 8I20 firmware upgrade
[03:56:55] <mshaver> Night! THANKS !!
[03:57:04] <pcw_home> 'nite all
[03:57:14] <mshaver> Big progress all around I think.
[03:57:21] <mshaver> Night!
[10:04:11] <archivist_emc> archivist_emc is now known as archivist
[13:21:38] <jthornton> jepler-: 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. Is this wrong and should be __u32 and __s32?
[13:54:30] <andypugh> What are the symptoms of the issues with probing inside subroutines? Is it only a problem with MDI_COMMAND or something more widespread?
[13:59:11] <jthornton> andypugh: I probe with my plasma torch in a subroutine (separate file) without problems
[13:59:52] <andypugh> OK. You have probably guessed why I am asking.
[14:00:05] <jthornton> not yet
[14:00:34] <andypugh> The tool-lenght measuring forum thread
[14:00:41] <jthornton> ah, ok
[14:00:51] <jthornton> I'm a bit slow this morning
[14:01:47] <jthornton> * jthornton is reading the thread now
[14:01:51] <andypugh> I completely skipped the morning after being up till 4am doing remote hal component testing.
[14:06:02] <jthornton> I "touch off" my plasma torch for each cut using G92 to set the Z0 after I use G38.2 to touch off
[14:07:02] <andypugh> No auto tool changer on the Plasma then ? :-)
[14:07:28] <jthornton> lol, only one tool but several tips
[14:08:08] <andypugh> T1 = plasma, T2 = waterjet, T3 = laser, T4 = oxy-fuel T5 = Sharpie?
[14:08:14] <jthornton> the plasma torch is on a floating mount with a micro switch
[14:08:24] <jthornton> T6 spotting drill
[14:25:55] <jepler-> jthornton: yes, I think you're right
[14:43:51] <jthornton> ok, thanks
[14:51:48] <andypugh> jthornton: Which versions is your timer in? (I am editing the SimpleCycleTimer wiki page to point out an easier way)
[14:52:23] <jthornton> 2.5
[14:54:01] <SteveStallings> SteveStallings is now known as steves_logging
[15:01:45] <micges> wiki updated to release 2.4.6
[15:05:51] <JT-Hardinge> hi micges
[15:05:57] <micges> hi
[15:06:08] <JT-Hardinge> are you still working on vec2ngc?
[15:13:38] <micges> not really
[15:16:32] <JT-Hardinge> I just noticed that it scales up an inch drawing by 24.5 or something like that when it generates the g-code
[15:16:50] <JT-Hardinge> I'll try and figure it out if I can
[15:17:19] <JT-Hardinge> my goal is to use it for my plasma table
[15:25:16] <JT-Hardinge> micges: did you just loose interest in it or is there a problem with it?
[15:30:23] <micges> loose interest and no time
[15:30:31] <micges> but I can fix it for you
[15:31:16] <micges> send me some dxf that you have problem
[15:35:00] <JT-Hardinge> ok, one moment
[19:06:39] <andypugh> <swears at Aram's email>
[19:09:40] <skunkworks> heh
[19:10:48] <andypugh> Can't we persuade him to use Mach?
[19:30:02] <cradek> beware he's using pre-hostmot2 documentation
[19:30:38] <SWPadnos> more importantly re-hostmot2 software
[19:30:41] <cradek> I'm not sure hm2 was even in emc2.2
[19:30:42] <SWPadnos> err, pre
[19:30:45] <cradek> yes
[19:30:46] <SWPadnos> nope
[19:30:56] <cradek> no yes no
[19:30:58] <cradek> ok
[19:31:11] <SWPadnos> abort retry ignore cancel delete
[19:31:14] <SWPadnos> yes no
[19:31:18] <micges> fail
[19:31:33] <SWPadnos> oh right, forgot that one
[19:31:44] <SWPadnos> usually using floppy disks
[19:31:49] <micges> yes
[19:33:01] <alex_joni> fatal error
[19:33:03] <andypugh> He's out of support contract then, isn't he :-)
[19:33:40] <SWPadnos> I think he used up all 5 support incidents already
[19:33:59] <SWPadnos> some time in 2008, actually :)
[19:34:12] <alex_joni> I think he used up all chances for a support contract renewal too
[19:35:16] <psha> jepler, cradek: may i request merge of gladevcp branch?
[19:36:21] <cradek> I can do it
[19:36:33] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=gladevcp
[19:36:35] <psha> cgit
[19:36:44] <psha> git://psha.org.ru/psha/emc2.git gladevcp
[19:37:24] <psha> it's HAL Bar widget (like PyVCP one but with gradients), custom user signal handlers and gladevcp HAL file execution
[19:37:32] <psha> based on today master branch
[19:37:49] <cradek> $ git fetch git://psha.org/ru/psha/emc2.git gladevcp
[19:37:49] <cradek> psha.org[0: 207.190.239.235]: errno=Connection refused
[19:37:57] <psha> psha.org.ru
[19:38:09] <cradek> duh sorry
[19:38:10] <psha> i've not .org domain yet :)
[19:38:46] <psha> there are some cybersquatter sitting there!
[19:43:48] <cradek> psha: pushed
[19:44:35] <cradek> psha: I don't know how to test those changes so I blindly ran the testsuite and trusted you otherwise :-)
[19:45:48] <psha> there is test for gladevcp now
[19:46:01] <psha> cd lib/python/gladevcp; halcmd -f gladevcp-test.hal
[19:46:29] <psha> thanks
[19:46:40] <psha> i'll send announce to dev list as usual
[19:49:05] <CIA-41> EMC: 03cradek 07master * r5732974471f2 10/src/hal/user_comps/gladevcp.py: add -h <halfile> option to gladevcp for post-init hal commands
[19:49:06] <CIA-41> EMC: 03cradek 07master * r5c87bb5637df 10/lib/python/gladevcp/makepins.py: gladevcp: Fix errors with several UI files
[19:49:07] <CIA-41> EMC: 03cradek 07master * r2b78027d2982 10/lib/python/gladevcp/hal_widgets.py: gladevcp: Add inverted pins to toggle switches
[19:49:08] <CIA-41> EMC: 03cradek 07master * r84ff560c4eac 10/ (docs/man/man9/gladevcp.9 src/hal/user_comps/gladevcp.py): fix gladevcp_makepins warning
[19:49:09] <CIA-41> EMC: 03cradek 07master * r6c3c38c5eef4 10/ (3 files in 3 dirs): gladevcp: make -h give usage, use -H <halfile>
[19:49:10] <CIA-41> EMC: 03cradek 07master * ref4672400eee 10/ (88 files in 34 dirs): Merge branch 'master' into gladevcp-modules
[19:49:11] <CIA-41> EMC: 03cradek 07master * r8eb0fe608786 10/ (3 files in 3 dirs): Merge remote branch 'mhaberler/gladevcp-halfile' into gladevcp-modules
[19:49:12] <CIA-41> EMC: 03cradek 07master * r40c7236ea9bc 10/src/ (emc/motion/control.c hal/components/time.comp): Merge remote branch 'origin/master' into gladevcp-modules
[19:49:14] <CIA-41> EMC: 03cradek 07master * r586eb6d140d6 10/lib/python/gladevcp/ (hal_bar.py hal_python.xml hal_pythonplugin.py): gladevcp: Added HAL Bar widget like one in PyVCP
[19:49:16] <CIA-41> EMC: 03cradek 07master * ree48a44055f9 10/lib/python/gladevcp/ (widget-gladevcp-hal_hbar.png widget-gladevcp-hal_vbar.png): gladevcp: Added icons for HBar/VBar widgets
[19:49:18] <CIA-41> EMC: 03cradek 07master * r0452519669e3 10/lib/python/gladevcp/ (gladevcp-test.hal gladevcp-test.ui): gladevcp: Added HAL HBar/VBar to tests
[19:49:19] <CIA-41> EMC: 03cradek 07master * r83c97888b197 10/src/hal/user_comps/gladevcp.py: gladevcp: Added user defined callbacks
[19:49:20] <CIA-41> EMC: 03cradek 07master * rbcabb9532b43 10/lib/python/gladevcp/ (7 files): Merge branch 'gladevcp-bar2' into gladevcp-modules
[19:50:14] <andypugh> Is it possible to setup halrun in such a way that error messages are visible?
[19:51:02] <mhaberler> andypugh: in gladevcp?
[19:51:15] <andypugh> No, in generic emc2
[19:53:25] <andypugh> For example, mshaver was setting his 8i20 to 20A (halcmd: setp hm2_5i20.0.8i20.0.0.maxcurrent 20) which causes an error message (you can't go that high, I am ignoring you) but you don't get to see those messages in halrun.
[19:55:27] <andypugh> They only seem to appear in dmesg
[19:59:22] <SWPadnos> they're messages from kernel modules, so they generally go to the log
[20:00:16] <SWPadnos> I think there's a way to print RTAPI messages to the console or to a file, but I don't know the mechanism
[20:01:20] <andypugh> OK. I guess I will just have to stop making errors.
[20:02:33] <micges> andypugh: rtapi_print_msg(RTAPI_MSG_WARN,
[20:03:20] <andypugh> Isn't that just a different masking level?
[20:03:52] <micges> no idea
[20:04:43] <andypugh> I am talking about RTAPI_MSG_ERR messages. They get printed (and appear in Axis) but not the halcmd prompt
[20:07:44] <micges> halcmd is userspace program and it's use printf
[20:08:02] <micges> so it's showed in terminal
[20:08:22] <micges> drivers and rest realtime code can't do that so they write to log
[20:09:19] <andypugh> OK, so I guess that the messages get into Axis by Axis polling the log?
[20:11:16] <SWPadnos> no, there's a "send user message" function in RTAPI (or somewhere in the RT/kernel code anyway)
[20:11:49] <SWPadnos> those messages go through the NML error channel I believe
[20:14:31] <andypugh> Anyway, the point is that I am not missing a trick, Axis displays error messages from RT code, but halrun doesn't. I just thought it might be an option
[20:15:10] <SWPadnos> I don't think halrun could do it, since you generally aren't running emc with halrun
[20:15:26] <micges> SWPadnos: yes there are 3 nml channels: cmd stat and error
[20:15:31] <SWPadnos> emc is what gets all those NML channels set up
[20:15:38] <andypugh> Ah!
[20:15:57] <andypugh> Talking of NML...
[20:16:07] <SWPadnos> micges, I know that. I don't know which particular 3-channel "connection" is the one that AXIS gets it info from though :)
[20:16:33] <SWPadnos> oh, NML talk. time for me to take a shower or make coffee or something :)
[20:16:37] <andypugh> There is an NML set acelleration command/symbol/token. Is that any use to Spiderdab?
[20:17:53] <SWPadnos> I'm not sure whether you can (a) issue that command while the machine is on or (b) assume that it will have any effect on already planned motion or (c) assume that it will do anything for HAL (since HAL doesn't really deal with NML)
[20:22:09] <andypugh> OK, will give up on that than.
[21:32:37] <andypugh> ping pcw_home!
[21:32:56] <andypugh> Or, alternatively, is there a way to search the IRC archives
[21:50:32] <alex_joni> andypugh: theoretically they should be indexed
[21:50:43] <alex_joni> so the search on the linuxcnc.org page should get them
[21:55:34] <andypugh> Worth a try
[23:08:13] <andypugh> pcw_home: Are you awake?
[23:32:54] <pcw_home> Just back
[23:40:24] <andypugh> Ah, I was composing a lengthy email.
[23:40:34] <andypugh> It probably works better that way anyway.