Back
[17:54:14] <moopy> are there any docs on how halrun works in python?
[17:57:01] <jepler> halrun is a shell script which starts realtime, runs halcmd, and then stops realtime. It has nothing to do with Python.
[17:57:27] <moopy> I want to create program that will config motors like stepconf wizard
[17:58:13] <moopy> but in stepconf all that is defined is halrun = self.halrun
[17:58:41] <jepler> self.halrun = halrun = os.popen("cd %(panelname)s\nhalrun -sf > /dev/null"% {'panelname':panelname,}, "w" )
[17:59:01] <moopy> so where is code that opens a pid and executes halrun and pipes data to halrun?
[17:59:10] <jepler> the halrun attribute of a stepconf App is a pipe to a halrun program with the flags -sf
[17:59:40] <jepler> -f without a filename indicates that it accepts commands from standard input, and -s means that its output is formatted in a way that is more useful for scripts (as opposed to the normal way of formatting data for interactive use)
[18:00:11] <moopy> i only been learning python for the last 5 days
[18:00:28] <moopy> but i think you may have explained everything to me
[18:00:30] <jepler> in Python that object has a .write() method just like any file object does. so you can halrun.write("""command to be interpreted by halcmd""")
[18:00:41] <jepler> when it's .close()d, halrun shuts down realtime and quits
[18:00:59] <jepler> depending on what you are doing it may make more sense to run your Python script inside halrun, rather than the other way around
[18:01:12] <cradek> weird - did I imagine that there used to be docs for [DISPLAY]GEOMETRY? there's nothing in
http://www.linuxcnc.org/docs/devel/html/gui_axis.html
[18:01:27] <cradek> (5axis sim doesn't rotate the cone right for C)
[18:01:41] <cradek> it has GEOMETRY=XYZCBW
[18:01:46] <jepler> the reason that stepconf doesn't do this is so that the user can do things like go back to the first tab and enter an entirely different information (such as the parport address), so the parport component needs to be reloaded each time an axis is tested.
[18:02:28] <jepler> cradek: the documentation of GEOMETRY got moved to
http://linuxcnc.org/docs/html/config_ini_config.html#sub:[DISPLAY]-section
[18:02:50] <cradek> thanks
[18:03:23] <jepler> maybe the geometry should be BC instead of CB? Not sure..
[18:04:37] <cradek> yes
[18:06:08] <CIA-4> EMC: 03cradek 07v2.4_branch * r60409b0c6e16 10/configs/5axis/5axis.ini: fix cone tilting in AXIS, and open limits on C
[18:27:14] <moopy> I think i am missing something also, seems when I run halrun in python popen it shows "RTAPI: ERROR: could not open shared memory (errno=2)
[18:28:02] <moopy> in source tree there is script emc-environment,
[18:28:14] <moopy> I get the feeling this should be run?
[18:28:40] <cradek> yes, you source it (in bash: . emc-environment)
[18:29:13] <cradek> errno 2 is no such file or directory
[18:30:07] <moopy> but i am not running it from source tree, how does stepconf handle this?
[18:30:27] <cradek> please describe what you're doing
[18:30:30] <moopy> it is just a path problem then?
[18:31:05] <moopy> i am writing a python script to config my motors like stepconf
[18:31:48] <moopy> I want to take all the parameters configured in gui and run halrun and write them out to test the config
[18:31:55] <cradek> ok let's do some troubleshooting - at the shell try running halrun
[18:31:58] <cradek> it should say halcmd:
[18:32:05] <moopy> all than works
[18:32:23] <cradek> ?
[18:32:40] <moopy> damkn something seems different this time
[18:32:53] <moopy> now says halrun already running
[18:33:59] <moopy> sorry seems all working now i have run halrun -U
[18:34:15] <moopy> must be pebcak
[18:34:47] <cradek> ok, good
[18:34:52] <moopy> yes seems working in python now
[18:34:58] <moopy> thanks for help
[18:35:04] <cradek> welcome
[18:39:10] <aystarik1> is it possible to call homing sequence from G-code somehow? Mach seem to be able to that with G28.1, but EMC only stores variables at it...
[18:39:20] <jepler> aystarik1: no, it is not.
[18:40:22] <aystarik1> custom M-code ?
[18:43:17] <jepler> no, because you can only home in MANUAL mode but you execute gcodes in MDI and AUTO mdes.
[18:43:20] <jepler> modes
[18:44:15] <cradek> with G53 you can move in absolute machine coordinates to your home location, but that's not the same as homing (searching for switch and/or index)
[19:13:26] <aystarik1> jepler, cradek: thanks, clear now :)
[20:45:03] <Dave911> Does anyone know what happens when the Mesa Hostmot2 driver - Stepgen in position mode - rolls over it's internal 32 bit position counter? I have EMC2 linked to an indexing conveyor that continually increments it's position though a machine. Everything is working great.
[20:48:27] <cradek> I think in the firmware it's 16 bits and inside the hal driver it's 64 bit
[20:51:04] <Dave911> I think I passed the 16 bit limit long ago :-) .... so perhaps that rolls over nicely. So the float to counter interface is actually 64 bits?
[20:52:44] <andypugh> You probably need to ask Seb, or look in the source.
[20:53:06] <cradek> yeah, I was trying to look in the source, but I don't follow it well enough to pretend I'm an expert.
[20:53:18] <Dave911> Perhaps you told me this before .. as this sounds familiar..
[20:53:37] <jepler> hi Dave911
[20:53:51] <Dave911> I'm more concerned about what happens when it rolls over.. Hi Jepler
[20:54:22] <Dave911> That Limit3 works really nice with the parameters set as pins.. :-)
[20:54:57] <jepler> cool. If it's tested and working I'll put that change in master
[20:55:35] <jepler> chris is right, the stepgen position in the fpga is 16 bits of steps plus 16 bits of fractional steps ("16.16 bit fixed-point") and inside hostmot2 it's in 48.16 fixed-point
[20:56:11] <jepler> only when you exceed 2^48 steps in one session will you have trouble. When that happens, I suspect the position will be wrong (go from extremely positive to extremely negative)
[20:56:21] <Dave911> Yes it is actually in a running machine on a machine with 3 second cycle times and the customer likes to make changes on the fly.. so I would say it is solid.
[20:56:50] <Dave911> With 2^48 counts I should be fine. I was thinking that it might roll over in 32 bits.
[20:57:00] <jepler> 48 bits should do you fine -- that's 1.4 trillion rotations on a 200-step motor
[20:57:38] <Dave911> Yep.. I think the motors may wear out before that limit is met.
[20:58:02] <jepler> I don't know that I've ever seen a step motor rated for lifetime rotations
[20:58:17] <cradek> pretty sure if you ever roll over, you'll get a following error, and emc will stop
[20:58:45] <jepler> but say it's actually a 10-microstep motor and you're moving the motor at 6000 rpms, you'll reach the 48-bit limit in 44 years
[20:59:39] <cradek> ha, 6000 rpm stepper
[20:59:48] <Dave911> No, but I think that bearings are rated in that fashion at some point. They will have a plant power outage before the limit is reached. :-) Geez, only 44 years.. Better put that on my calendar. ;-)
[21:00:15] <andypugh> Well, the following error will be a hint it is time to lubricate the motor and install some kernel updates :-)
[21:01:22] <Dave911> Actually this is driving a step and direction inteface to a servo which has 768 counts per inch of chain travel, and it runs 36 inches per cycle. Once cycle each 3 seconds.. They are running 10+ hours per day right now and going to 2 shifts shortly.. I think I am still pretty safe. :-)
[21:01:55] <Dave911> andypugh: Or junk the machine..
[21:03:05] <cradek> I think we have several devices with 24 bit encoder counters - they definitely handle rollover
[21:03:24] <jepler> then you get 34,842 centuries before overflow
[21:03:29] <jepler> you'll hit a software bug long before that happens
[21:07:06] <Dave911> 34,842 centuries.... geez now how do I tell the customer that we will all be long deceased by the time that is an issue??
[21:07:45] <cradek> "we will all be long deceased by the time that is an issue."
[21:07:50] <jepler> each hal driver has different code to handle widening from a short hardware register size to a large software register size
[21:07:55] <jepler> I bet some of them are wrong
[21:08:26] <Dave911> ;-)
[21:08:26] <cradek> some have been rewritten several times - surely that means they're right?
[21:11:47] <jepler> Dave911: is this the patch that you tested?
http://emergent.unpy.net/files/sandbox/0001-make-limit3-pins-into-parameters.patch
[21:11:55] <Dave911> I figured I had about 10 days for them to roll over a 32 bit signed register... if they don't have any production slowdowns.. and I really didn't want to get a call in 8 more days.
[21:12:23] <Dave911> jepler: That is the one!
[21:14:01] <jepler> thanks for the report. pushed to master..
[21:14:03] <jepler> bbl
[21:14:11] <CIA-4> EMC: 03jepler 07master * rba7e20f35ee1 10/src/hal/components/limit3.comp: make limit3 pins into parameters
[21:20:48] <Dave911> I use ClassicLadder to load a position into the Limit3. The limit3 output is run into a Hostmot2 stepgen to run two axes back and forth and index the third axis. A PLC that was already on the machine supplies signals to the PC running EMC2. The CL interface via Modbus :-) reliably supply position, accel, and velocity values to the PC from the PLC. The EMC2 PC runs headless. I set...
[21:20:50] <Dave911> ...it up this way to mimic the old indexer servo drives that I replaced. The servo drives had built in homing functions that I took advantage of so I didn't have to deal with homing inside the EMC2 PC.
[21:21:53] <Dave911> Jepler: Isn't that description actually backwards? That patch makes parameters into pins.
[21:28:23] <jepler> Dave911: well shoot, you're right
[21:28:29] <jepler> too bad I can't change it now that I've pushed it :-/
[21:32:33] <Dave911> oh well.. it works anyway. :-)
[21:36:58] <skunkworks> Dave911: did you see this?
http://www.youtube.com/watch?v=4nuRea6615s
[21:37:14] <skunkworks> emc is cool :)
[21:39:45] <Dave911> Skunkworks .. how are you getting the barcode data into CL.. Modbus?
[21:40:20] <Dave911> Very nice.. :-)
[21:41:19] <Dave911> Looks like you K&T conversion is coming along nicely.
[21:41:29] <Dave911> your
[21:41:31] <skunkworks> nope - I am using 15 i/o from the mesa card
[21:41:47] <skunkworks> converting the 15 'bits' into a number
[21:42:29] <skunkworks> using 2 mesa cards so 96i/o + 8 encoder counters/+/-10v
[21:43:00] <Dave911> So that bar code reader has a digital interface?
[21:43:17] <skunkworks> the barcode reader is 15 switches :)
[21:43:26] <skunkworks> mechanical barcodes
[21:43:34] <Dave911> Did that come on the machine?
[21:43:42] <skunkworks> yes
[21:44:08] <Dave911> Wow... that was really advanced back then.. I had no idea.
[21:44:19] <skunkworks> you can see it in this picture
http://electronicsam.com/images/KandT/oldkandt.JPG
[21:44:27] <skunkworks> (that is from the manual)
[21:48:30] <Dave911> The control panel behind the operator is almost as big as the machine.. You can clearly see that reader in the picture.
[21:51:41] <Dave911> Are K&T parts hard to find now? So Giddings and Lewis bought them up also. G&L bought up a number of machine tool makers apparently.
[21:53:35] <skunkworks> well - we have never tried to get parts for it. We did get a parts manual for it. We have 2 identical machines - using 1 for parts - plus we have extra parts when we purchased it.
[21:55:57] <Dave911> Two machines ....OK.. I remember you saying that a while ago... That was smart. Extra parts is always a good idea. Are you getting close to being done with the conversion?
[21:57:42] <skunkworks> heh - I would say a few months yet. axis should be moving soon. (here is the x and z servo mount
http://electronicsam.com/images/KandT/conversion/servo/mount2.JPG)
[21:59:43] <Dave911> Big motors! Do those directly drive ball screws?
[22:00:02] <skunkworks> no - 2:1 about
[22:00:16] <Dave911> Gear drive?
[22:00:31] <skunkworks> no - belt
[22:00:46] <skunkworks> (we are adding that) - it was hydraulic.
[22:01:14] <skunkworks> we are still using the z axis drive train. We where able to get the backlash out of the geartrain
[22:02:02] <Dave911> That is a ton of work you are doing then.
[22:02:03] <skunkworks> the old control used 1 hydraulic servo to run x,z and b. so we had to get in there to hook separate servos for each
[22:02:50] <Dave911> That is a tough conversion.
[22:03:23] <skunkworks> yeh - but it is there. ;) pre
http://electronicsam.com/images/KandT/conversion/xaxis/start.JPG
[22:03:33] <skunkworks> post
http://electronicsam.com/images/KandT/conversion/xaxis/3shafts.JPG
[22:03:42] <Dave911> Should be a very capable machine when you are done though.
[22:04:22] <skunkworks> yes - it worked very well with the old ge controller - emc should be awesome
[22:05:52] <skunkworks> 3 axis movements will be nice also ;)
[22:06:38] <Dave911> So those three shafts were switched between that hydraulic motor somehow?
[22:06:43] <skunkworks> yes
[22:06:58] <skunkworks> it had a clutch brake system in that gearbox.
[22:07:22] <skunkworks> http://electronicsam.com/images/KandT/conversion/xaxis/open.JPG
[22:08:02] <Dave911> I didn't know you could control a hydraulic motor like that. Was that a conventional looking gear motor?
[22:08:48] <Dave911> Have you figured out how to use the linear encoders that were on it yet?
[22:09:21] <skunkworks> offset psiton
[22:09:25] <skunkworks> piston
[22:09:49] <skunkworks> no - not yet. want to get it running first with shaft encoders
[22:10:32] <Dave911> Interesting... I had a customer who tried to control a gear motor like that... It simply didn't work. Makes sense to get shaft encoders working first.. Perhaps you won't need linear encoders..
[22:10:42] <skunkworks> we should have 80ft-lb peak at the screws. 40 cont.
[22:11:08] <Dave911> That should be enough. :-)
[22:11:34] <skunkworks> it is about what it had with the hydraulic servos (although I think it was 80 cont ;)
){kind=link}
