Back
[00:01:55] <penguin> m64/65 turns off/on the digital outs
[00:02:14] <penguin> should be instantaneous
[00:02:26] <jlmjvm> k,dont see that 1 normally
[00:02:36] <davidf> from the emc2 docs: M64 & M65 happen immediately as they are received by the motion controller. They are not synchronized with movement, and they will break blending.
[00:02:49] <jlmjvm> p is usually a dwell
[00:03:11] <jlmjvm> for most things ive seen
[00:03:21] <penguin> but dwell? (sorry, i don't know this word)
[00:03:33] <jlmjvm> a pause
[00:03:48] <jlmjvm> try it without the p
[00:03:51] <penguin> P is a pause????
[00:04:09] <penguin> i think P is the digital pinout
[00:04:24] <davidf> M62
[00:04:24] <davidf> Turn on digital output synchronized with motion
[00:04:24] <davidf> M63
[00:04:24] <davidf> Turn off digital output synchronized with motion
[00:04:24] <davidf> M64
[00:04:25] <davidf> Turn on digital output immediately
[00:04:27] <davidf> M65
[00:04:29] <davidf> Turn off digital output immediately
[00:04:34] <penguin> P0, P1, P2, P3 are the digital outputs
[00:04:44] <jlmjvm> might be,in normal mill g-code ist a dwell
[00:04:44] <penguin> (i think)
[00:04:49] <davidf> Can you use m62 / m63 instead?
[00:04:58] <penguin> yes, i will try
[00:05:16] <penguin> but, how I address to a specific output?
[00:05:29] <davidf> that should do it. M65 stops the motion. M62 or m63 won't, I think.
[00:05:38] <jlmjvm> prolly not your problem,im only used to milling machines
[00:06:11] <davidf> Here:
http://www.linuxcnc.org/docs/devel/html/gcode_main.html#sec:M62-to-M65
[00:06:14] <penguin> you use m62/63 with an additional command?
[00:06:35] <davidf> Yes, same way P0 to P3.
[00:06:42] <penguin> or in the begining of your code, you define the output
[00:07:04] <davidf> Check that link above.
[00:07:52] <penguin> in the link says P is the output
[00:07:56] <penguin> not a pause
[00:08:15] <penguin> mmm...
[00:09:31] <penguin> this is right?: G01 X1.2000 M62 P0
[00:09:38] <penguin> ths syntaxis
[00:09:55] <penguin> can be M-words and G-words in the same line?
[00:09:58] <davidf> That's right. jlmjvm was thinking of M60 (Pause) I think. With that one the P word is for how many seconds to pause.
[00:10:37] <davidf> I don't know. If in doubt put them on separate lines.
[00:11:01] <penguin> i tried everything... i have this problem for months
[00:11:05] <penguin> :s
[00:11:31] <penguin> i connected the laser to the Z direction
[00:11:49] <penguin> so, the laser turn on when Z is down
[00:12:03] <penguin> and the laser turns off when Z is up
[00:12:17] <penguin> but Z movements have a little pause
[00:12:28] <penguin> M64/65 also have a pause
[00:12:44] <penguin> i tried everything and everything have a pause
[00:13:04] <davidf> I see. I'm thinking...
[00:14:40] <penguin> the base period is low enough
[00:16:41] <davidf> This one is beyond me. I'm not that knowledgeable. I would ask SWPadnos about it. He should be here later.
[00:16:51] <davidf> SWPadnos, you back yet?
[00:17:22] <penguin> (thanks davidf)
[00:17:43] <davidf> Sorry I can't help you.
[00:18:20] <penguin> no, really thanks for try to contact SWPadnos
[00:18:43] <penguin> let see if he or anyone can help me
[00:20:37] <davidf> bbl
[00:36:02] <penguin> SWPadnos, are you there?
[00:36:45] <penguin> please, if anyone can read the delay problem
[00:40:03] <archivist> what do you mean by pause, mass (Z) takes time to accelerate you may need to think your system through a bit
[00:40:30] <archivist> see the details on the wik about the trajectory planner
[00:42:54] <penguin> what about the digital output delays?
[00:43:07] <penguin> or the pwm delay
[00:43:16] <penguin> when change the pwm value
[00:43:28] <penguin> i have a delay problem
[00:43:33] <penguin> with everything
[00:44:07] <penguin> in a lathe this is not signifficant, but with a laser is a headache
[00:44:34] <penguin> everytime i change the pwm value, there is a pause
[00:44:34] <archivist> some mention on the wiki as a wish it seems
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?SynchronizedOutputs
[00:44:56] <archivist> but there is a user using lasers in production
[00:45:10] <penguin> who?
[00:46:58] <archivist> micges
[00:47:38] <penguin> how can i contact him?
[00:48:11] <penguin> he is not online in this moment
[00:48:48] <archivist> well past his bedtime now
[00:48:55] <archivist> and mine!
[00:49:07] <MattyMatt> reprap does sth similar by inventing the E axis to control the extruder
[00:50:30] <MattyMatt> 2 extra axes, I forget what the other one is. one for extruder temp, the other for extrusion rate
[00:50:48] <penguin> who else have used laser with emc?
[00:51:26] <penguin> i think laser moves faster than other applications
[00:51:52] <pfred1> theoretically quantum tunneling is faster :)
[00:52:46] <penguin> how i inmediately turn on/off a laser without delays?
[00:53:03] <pfred1> penguin enter the 12th dimension
[00:53:15] <MattyMatt> shutter
[00:53:28] <pfred1> here there is no such thing as no delay
[00:53:31] <penguin> i don't know what can be done with HAL programming
[00:54:45] <penguin> some people connect the laser to the Z direction pinout
[00:55:38] <penguin> but the acceleration takes time, and there is a delay
[00:55:51] <penguin> another alternative is use pwm output
[00:56:05] <penguin> but also there is a delay when change the pwm value
[00:56:37] <penguin> i don't know if the pwm clock must be programmed
[00:56:56] <penguin> in HAL, for example
[01:38:50] <davidf> SWPadnos, are you around?
[01:49:30] <davidf> I'll check back tomorrow.
[01:57:50] <SWPadnos> bummer, missed him by that much\
[01:57:53] <SWPadnos> -\
[01:59:09] <Valen> lol
[01:59:26] <Valen> SWPadnos, was thinking about that AVR thing
[01:59:28] <pfred1> SWPadnos are you a square?
[01:59:40] <Valen> theres no need to address the cards individually
[02:00:01] <SWPadnos> Valen, via a parallel port?
[02:00:05] <Valen> yeah
[02:00:14] <Valen> you could just write sequential bytes out to the stack of cards and they can just pick up the ones meant for them
[02:00:15] <SWPadnos> pfred1, depends on what you mean by square
[02:00:23] <Valen> then they reply in the same way
[02:00:30] <pfred1> SWPadnos well everyone kept asking if you were a round
[02:00:49] <SWPadnos> Valen, sure, if you clock the data through each card (a little like a SPI chain)
[02:00:58] <SWPadnos> pfred1, ah. I guess I'm more of an oval or something
[02:01:05] <Valen> run them all on a buss
[02:01:16] <pfred1> SWPadnos well no wonder they had no success
[02:01:48] <SWPadnos> well, you'll need jumpers to set which block of data each gets, and you'll need a very well-defined "reset your counters now" code/condition
[02:02:11] <Valen> I was thinking of some sort of interboard plug n prey system
[02:02:15] <Valen> or jumpers lol
[02:02:44] <SWPadnos> plug and pray is harder when there's a bus involved
[02:03:11] <SWPadnos> serial/daisy-chain schemes can work OK, but when all the cards share the data/address lines, who can tell who's first?
[02:03:56] <Valen> I reckon you issue a reset at the start of each sequence, just assert a line
[02:03:56] <SWPadnos> I thought you were talking about AVR debounce at first :)
[02:04:15] <SWPadnos> yeah, but how do the cards know whether they're first or last or somewhere in between?
[02:04:24] <Valen> hmm thats a point
[02:04:41] <SWPadnos> and, more importantly, how many bytes to ignore (assuming they don't all use a fixed address block size)
[02:04:43] <Valen> unique ID perhaps?
[02:04:47] <SWPadnos> jumpers
[02:04:49] <SWPadnos> :)
[02:04:52] <Valen> yeah probably right
[02:04:56] <Valen> simple which is good
[02:04:56] <SWPadnos> but that's not automagic
[02:05:05] <Valen> meh, its probably easier
[02:05:37] <Valen> only hitch to the scheme is if you have different types of board
[02:05:43] <SWPadnos> and a fixed block size, so there is no question about which bytes go where
[02:06:04] <SWPadnos> hmmm, well actually maybe it is possible to do it automatically, you just need extra bits
[02:06:10] <SWPadnos> in the bus
[02:06:27] <Valen> yeah, I was wondering if a fixed size might get messy in terms of supporting things like I/O cards
[02:06:48] <SWPadnos> you can't directly parallel all the cards
[02:06:57] <Valen> yeah it should be ok
[02:07:05] <Valen> you just need an initilisation sequence
[02:07:17] <SWPadnos> but, you can do something like use 8 of the ground lines as "base address" lines
[02:07:40] <SWPadnos> so the thing that plugs directly to the PC has all of those grounded
[02:07:44] <SWPadnos> address 0
[02:08:07] <SWPadnos> and you use an 8-bit port to output the base address of the next card on your "output connector"
[02:08:18] <SWPadnos> the lines from the parport go straight through
[02:08:27] <Valen> where they use DIP to set a bus ID then communicate with each other and the host as to how many data blocks they require and what type of card they are
[02:08:31] <SWPadnos> the "address" lines go in on one side and out on the other
[02:08:51] <Jymmm>
[02:08:54] <SWPadnos> and you can use any number of bytes per card, since the CPU can just add 1, 2, 7, 39 to the input address
[02:09:54] <SWPadnos> I'm not sure yet how the PC could detect the number of bytes to send
[02:09:55] <Valen> I'm not seeing an advantage to it really
[02:10:19] <SWPadnos> no user configuration, and variable-size (ideal efficiency) address blocks
[02:10:27] <Valen> ok so on poweron all the cards sit in a wait state
[02:11:03] <Valen> when the host is ready to play it signals for a sound off, and gets the cards to enumerate on the bus describing themselves
[02:11:24] <Valen> you use DIP switches to give each card a unique ID
[02:11:41] <SWPadnos> sure, you can do that too
[02:12:30] <Valen> you need some way of uniquely identifying the cards and the DIP switches as you say are probably easiest ;->
[02:12:35] <SWPadnos> make the first 16 bytes of EPP address space be used for identification, (each card occupies one byte, identified by its ID jumpers)
[02:12:51] <SWPadnos> yes, but the user does have to do that themselves
[02:13:05] <Valen> yeah, so use that once you have it ;->
[02:13:13] <Jymmm> I prefer a 8192 bit UUID key
[02:13:27] <SWPadnos> Jymmm, ok, you can enter that on the DIP switches
[02:13:32] <Valen> Jymmm you can set that on the jumpers
[02:13:34] <Valen> snap
[02:13:59] <Jymmm> Hey, they didn't that originally if you recall
[02:14:56] <Jymmm> did
[02:15:12] <SWPadnos> but only 16 or so switches :)
[02:17:22] <Valen> yah so in epp there are a few spare lines, we can use that to reset the clocks on the cards for the cycle
[02:17:49] <SWPadnos> in EPP there's an address cycle that you need to send first (you can set to any address)
[02:17:59] <Valen> ahh, no they are only for input to the host
[02:18:29] <SWPadnos> then there's a transfer type that is meant to auto-increment the address (or something like that)
[02:18:50] <Valen> we dont really care about address, there is only one "device" on the bus
[02:19:07] <SWPadnos> read:
http://www.beyondlogic.org/epp/epp.htm
[02:19:11] <Valen> i am
[02:19:19] <SWPadnos> ok :)
[02:19:42] <penguin> SWPadnos, the guys says you could know some about the delay problem
[02:19:43] <SWPadnos> setting address zero is a nice way of resetting the counters, don't you think?
[02:19:58] <SWPadnos> penguin, um, maybe
[02:20:04] <SWPadnos> what delay problem are you talking about?
[02:20:06] <Valen> any set address cycle would do
[02:20:24] <Valen> ok how bout this, set address 0 to do normal communications
[02:20:25] <penguin> when changes the pwm value, there is a delay
[02:20:38] <penguin> that pause a little the movement
[02:20:54] <penguin> this is for rastering with a laser
[02:20:59] <SWPadnos> ah, ok. are you Augustin Cruz?
[02:21:03] <penguin> yes!
[02:21:10] <penguin> i'm famous
[02:21:13] <SWPadnos> Agustin, sorry
[02:21:15] <SWPadnos> :)
[02:21:16] <Valen> IE set address 0, send bytes out for PWM/IO to all the daughter cards, and read in their replies
[02:21:32] <SWPadnos> Valen, isn't it different for read vs. write cycles?
[02:21:52] <Valen> for enumeration and config, set addresses 1 through whatever and talk direct to the cards
[02:21:56] <SWPadnos> ie, you set up a read operation with address, then read all the data
[02:22:09] <SWPadnos> then separately set up a write operation and do all the writing
[02:22:41] <SWPadnos> well, except that you get EPP timeout errors for any address that doesn't actually have a card sitting on it (ie, no response)
[02:22:54] <Valen> then you know there isnt a card there
[02:22:57] <SWPadnos> one reason to use a small number of well-known addresses for enumeration
[02:23:06] <Valen> whats the timeout?
[02:23:10] <SWPadnos> yeah, but it takes 5 minutes to scan all the addresses
[02:23:12] <SWPadnos> no idea
[02:23:30] <Valen> true, make the number of scanned addresses small but configurable
[02:24:00] <Valen> i think you set an address as one operation then as a seperate one do reads and writes
[02:24:02] <SWPadnos> penguin, I don't know the answer to your problem. spindle can't work at the moment, because the motion queue is finished before the spindle speed is changed, and then new motion commands get queued
[02:24:25] <Valen> so you don't need to re-address things for each read and write
[02:24:43] <SWPadnos> if the motion-synchronized codes (M6x) also don't work, then we probably have a bug to fix
[02:25:36] <SWPadnos> I think Eric Johnson pointed out that you can't get very good resolution at normal laser etching speeds, unless you radically speed up the servo cycle
[02:25:56] <SWPadnos> the answer is probably to write a HAL component that can stream data to the laser at higher speed
[02:25:57] <Valen> with SMP on an atom I run the servo at 5khz without a problem
[02:26:16] <Valen> I have run it at 10khz on a dual Xeon
[02:26:37] <SWPadnos> the HAL component would take the position as an input, and output a bit or PWM value that's from a table or interpolated from a table
[02:26:48] <SWPadnos> sure, you can do that on fast enough hardware
[02:26:57] <penguin> to speed up the servo cycle i need to decrease the baser period?
[02:27:02] <SWPadnos> with the right interface hardware (ie, not a parallel port :) )
[02:27:14] <SWPadnos> not the base period, the servo period
[02:27:28] <SWPadnos> is this machine software stepped?
[02:27:35] <penguin> servo period doesnt appear in the stepcong wizard
[02:27:38] <penguin> yes
[02:28:44] <SWPadnos> well, if you can break the laser control data into single-step chunks, you might be able to output that bit every time a step goes out
[02:28:46] <penguin> i mean, there is a IC outside that control the steppers with step and direction pins
[02:28:51] <SWPadnos> oh
[02:29:01] <SWPadnos> yes, that's what I was talking about
[02:29:07] <SWPadnos> using a parallel port?
[02:29:12] <penguin> yes
[02:29:56] <penguin> i think that S and M6x command have a ms delay
[02:30:11] <penguin> S -> PWM
[02:30:18] <SWPadnos> no, the M62/M63 codes should be synchronized to the motion
[02:30:39] <penguin> G01 X1.3 M62 P0
[02:30:45] <penguin> the syntaxis is right?
[02:30:53] <SWPadnos> could be, I'm not sure :)
[02:31:04] <SWPadnos> but note that the output will change at the end of the move
[02:31:08] <SWPadnos> (I think)
[02:31:21] <Valen> ECP supports DMA, AVR's support DMA, I wonder how hard it would be to get it all to play nice
[02:31:31] <SWPadnos> hard
[02:31:35] <SWPadnos> easy
[02:31:39] <Valen> high end AVR's admitadly
[02:31:41] <SWPadnos> easier once it's done
[02:32:04] <SWPadnos> well, they support internal DMA between memory and peripherals, I don't think that means that they support being targets for ECP DMA
[02:32:13] <Valen> yeah probably right
[02:32:31] <Valen> I didn't know if the DMA was "braught out'
[02:32:43] <pcw_home> SWPadnos table lookup method looks like the way to go for a software step based system
[02:32:45] <pcw_home> if M62 and M63 wont work (are M62 and 63 updated only at the servo thread? that would explain the 1 mS)
[02:32:47] <pcw_home> Rastering to MHz rates would be pretty easy with some hardware help
[02:32:48] <pcw_home> (A FIFO kept filled by EMC that parcels out raster bits/bytes at a rate determined by the encoder count/stepgen)
[02:33:04] <Valen> hah use JTAG or whatever to directly manipulate the memory state
[02:33:09] <penguin> can you imagine EMC engraving a picture with a laser?... I'm trying to do that for months, but this delay problem is a headache
[02:33:28] <SWPadnos> pcw_home, yes, those outputs are controlled at the servo rate
[02:33:39] <SWPadnos> emc isn't designed for that
[02:34:04] <pcw_home> So bumping up the servo rate would help
[02:34:24] <penguin> how can i change the servo rate?
[02:34:31] <Valen> edit the ini file
[02:34:34] <SWPadnos> change SERVO_PERIOD in the ini file
[02:35:04] <penguin> i will try... the servo rate is related to M6x commands too ?
[02:35:10] <SWPadnos> but be careful, make sure you change it in smallish increments, and bump it back up if the PC starts to respond slowly
[02:35:25] <Valen> penguin do you have a multi core machine?
[02:35:26] <SWPadnos> the M6x commands are executed by the motion controller, which runs at the servo rate
[02:35:34] <penguin> yes.. dual core
[02:35:47] <Valen> you might want to follow the SMP instructions on the wiki
[02:36:06] <SWPadnos> what CPU and speed is your PC?
[02:36:26] <penguin> 2 ghz
[02:36:28] <Valen> its not too hard to do, you can download the SMP kernel, then you just need to compile EMC
[02:36:40] <Valen> 2Ghz what
[02:36:50] <penguin> is not intel
[02:37:00] <SWPadnos> that narrows it a little :)
[02:37:03] <Valen> lol
[02:37:07] <penguin> i dont remember if celeron or athlon
[02:37:14] <Valen> 2Ghz AMD should be pretty good
[02:37:14] <SWPadnos> celeron is Intel
[02:37:17] <Valen> celeron is intel
[02:37:18] <penguin> amd!
[02:37:26] <pcw_home> Since you will be doing minimal I/O at the servo rate (unlike an actual servo machine)
[02:37:28] <pcw_home> seems like the servo thread could be quite high on a fast machine.
[02:37:39] <SWPadnos> Athlon or possibly Sempron (dunno if they ever made dual-cores)
[02:38:02] <SWPadnos> depnds on a lot - chipset, video, network, unknown other things .. :)
[02:38:10] <Valen> I would suggest going for SMP, then cranking your servo rate until you get errors
[02:38:44] <SWPadnos> SMP only helps by putting the realtime code on one CPU (leaving the other one for anything else)
[02:38:44] <penguin> smp... i dont know what it is, but i will search
[02:39:13] <SWPadnos> and you need to use isolcpus=1 on the kernel load line if you want to prevent non-RT stuff from executing on the CPU that the RT tasks use
[02:39:21] <SWPadnos> "symmetric multiprocessing"
[02:39:24] <Valen> multi processing, basically you will use 1 CPU to run all your desktop etc, and one for running realtime stuff
[02:39:30] <SWPadnos> ie, more than one CPU (or core) of the same type
[02:39:37] <Valen> it can really help your latency numbers
[02:39:56] <SWPadnos> it's usually not that big a difference, actually, but it's worth a try
[02:40:17] <SWPadnos> at worst, you'll still have better performance from the PC, since both CPUs will be used
[02:40:57] <Valen> I found it made a big difference to latency, about halved it on my atom and went from ~8k to 2k on the Xeon
[02:41:02] <penguin> there is a live CD for emc 2.4 yet?
[02:41:08] <SWPadnos> no
[02:41:23] <penguin> maybe there is a bug fix
[02:41:31] <penguin> that i can use
[02:41:49] <Valen> you can compile 2.4 yourself, its pretty easy
[02:42:01] <Valen> but it sounds like thats not your problem
[02:42:07] <penguin> nope
[02:42:20] <penguin> freaking delay problem
[02:42:27] <penguin> FDP
[02:44:07] <Valen> SWPadnos:
http://www.fpga4fun.com/EPP1.html i think explains using the port nicley
[02:45:37] <penguin> do you know someone experienced in lasers and EMC ?
[02:45:38] <SWPadnos> yep, looks good
[02:45:48] <SWPadnos> penguin, not for rastering :)
[02:45:54] <penguin> damn
[02:46:07] <SWPadnos> it's been discussed, but I don't know that anyone has actually written the code you'd need to do it well
[02:46:48] <penguin> this is a very important application. I think EMC should have better support for rastering
[02:47:01] <SWPadnos> feel free to write it, or hire someone to do so :)
[02:47:16] <SWPadnos> and/or send a nice laser rastering machine to a developer
[02:47:39] <penguin> it's a pretty obvious application... not all is vector
[02:48:14] <SWPadnos> well, it's obvious, but it's not what emc is designed for
[02:48:36] <SWPadnos> emc is about motion control, rastering is simple motion control and complex "machine control"
[02:49:04] <SWPadnos> it's not impossible, especially if you're willing to write some software, and/or help get it written
[02:49:25] <SWPadnos> it's not easy though, since that wasn't a design goal for emc
[02:49:40] <Valen> buy SWPadnos peruvian coffee ;->
[02:50:14] <cradek> I've already offered to do the work if someone gives me a laser machine. I'm 100% serious.
[02:50:16] <Valen> SWPadnos would he perhaps be better off doing something to combine with EMC, to handle the raster stuff seperatly?
[02:50:28] <cradek> I agree a lot of people seem to want it.
[02:50:41] <grommit> Why is it an important application? (not familiar with it)...
[02:50:47] <Valen> what is the actual issue?
[02:50:53] <SWPadnos> Valen, yes, as I said, a HAL module could do it just fine, it just hasn't been written yet
[02:52:00] <SWPadnos> I
[02:52:13] <SWPadnos> I'd also do it if someone donated a nice laser machine to me :)
[02:52:30] <penguin> a HAL module could do the job?
[02:52:52] <SWPadnos> yes, I think so
[02:53:07] <SWPadnos> in fact, you probably don't need the motion controller of emc2 at all
[02:53:15] <pcw_home> The main problem is the high resolution, A laser could well be fitted to a multi axis
[02:53:17] <pcw_home> head for engraving fancy curved objects where a raster would not work.
[02:53:18] <pcw_home> so a general solution might still be a EMC like motion controller
[02:53:19] <SWPadnos> since all you need to do is move back and forth a lot
[02:53:42] <SWPadnos> switch between the two
[02:53:53] <SWPadnos> (with different machine configs, at worst)
[02:54:16] <penguin> yes, i have a raster configuration and a vector configuration
[02:54:41] <penguin> in raster configuration, there one fast axis
[02:54:50] <penguin> and one slow axis
[02:55:09] <penguin> but the fast axis pause everytime the pwm changes
[02:55:38] <penguin> (pause a few ms)
[02:56:07] <SWPadnos> do you always (or can you always) use bitmap images to get the laser PWM data?
[02:56:29] <penguin> yes, you can transform graylevel to PWM
[02:56:55] <penguin> black -> 100%
[02:57:01] <penguin> white -> 0%
[02:57:16] <penguin> it's direct
[02:58:05] <penguin> damn delays... :(
[02:58:23] <SWPadnos> are you using something like image-to-gcode, or do you have your own software to generate the g-code?
[02:58:52] <Valen> penguin what are the delays?
[02:58:55] <penguin> i use my own program in scilab for generate g-code from any image
[02:59:03] <penguin> works fine
[02:59:44] <penguin> Valen, the delays everytime changes the pwm value
[03:00:06] <SWPadnos> HAL provides components that are a bit like the blocks in scilab (but no fancy graphical editor)
[03:00:12] <Valen> what delays and how is it set up?
[03:00:13] <penguin> i can't get a constant speed, because pwm changes produce small pauses
[03:00:29] <Valen> what PWM are you using/changing?
[03:00:48] <SWPadnos> there are step generators, velocity and acceleration limiters, components that can capture or play back a block of data, etc
[03:01:19] <penguin> Valen, the spindle pwm output
[03:01:31] <Valen> my first thought would be to use them as axies
[03:01:54] <SWPadnos> you could just write a GUI that takes in an image, and directly tells the motors do to the rastering, while also "playing back" the line of raster data (to the laser PWM output), you would have your rastering machine
[03:02:00] <SWPadnos> ^and
[03:02:05] <Valen> run it as XYZA or some such with A your laser output running as a servo system
[03:02:24] <Valen> leave A as 0 on the encoder, set P to 1 and give it a large ferror
[03:02:39] <SWPadnos> Valen, that doesn't work, because A (or any other axis) moves slowly to the new setting over the whole combined move
[03:03:00] <penguin> there is very few documentation about HAL programming
[03:03:05] <Valen> give it a G1 per pixel
[03:03:35] <SWPadnos> there is a ton of documentation about the design of HAL, how to load and connect components, and the components themselves
[03:04:06] <SWPadnos> most every component (except one or two I wrote) has a manual page that are at least "good"
[03:04:17] <SWPadnos> there is a complete HAL getting started guide
[03:05:02] <penguin> the programming occur inside the .ini file, right?
[03:05:23] <Valen> SWPadnos: whats the downside to XYZA with a G1 per pixel?
[03:05:23] <penguin> (.ini or .hal)
[03:05:34] <SWPadnos> HAL configuration is done in text files, yes
[03:06:20] <penguin> Valen: A axis have inertia too, like X, Y and Z
[03:06:39] <penguin> so, A changes are relatively slow
[03:06:47] <SWPadnos> penguin, see the HAL section here:
http://www.linuxcnc.org/docs/2.3/html/
[03:07:32] <Valen> penguin I am saying to make A your laser
[03:07:44] <Valen> you can give it near infinite acceleration
[03:08:28] <penguin> infinite acceleration is not enough... there is an aditional freaking delays from nowhere
[03:08:30] <Valen> so you raster with a set of G1 Y10 X23 A100; G1 Y10 X24 A50
[03:09:10] <Valen> so your saying that if you give EMC a G1 it wont put out the right value?
[03:09:59] <Valen> the A "encoder" is always 0, with a P term of 1 it will just adjust the "error" output instantly there is no inertia
[03:12:00] <Valen> there wont be a delay as its not going to upset the que
[03:12:21] <SWPadnos> Valen, A changes smoothly from 100 to 50 in the second move there, over the course of the entire move
[03:12:28] <penguin> SWPadnos, i look the site
[03:12:35] <SWPadnos> it doesn't change immediately to 50, regardless of the acceleration setting
[03:12:42] <penguin> there is a command: motion.servo.last-period
[03:12:46] <SWPadnos> there is a lot of information there
[03:13:02] <Valen> SWPadnos ahh but its not actually the position your after,
[03:13:18] <SWPadnos> it is, if the position value is used as the PWM value
[03:13:25] <Valen> I gots it
[03:13:58] <Valen> tell it to move the width of the pixel -.001mm (say), move the next .001 whilst adjusting power, then move the next pixel width
[03:14:01] <penguin> if i want to play with motion.servo.last-period, i need to write motion.servo.last-period=24 (for example)
[03:15:48] <SWPadnos> servo.last-period is an output parameter, it's just there for timing analysis
[03:16:20] <Valen> G1 Y10 X24 A100; G1 Y10 X24.01 A50; G1 Y10 X25 A50
[03:16:30] <Valen> lemme know what you think
[03:17:03] <penguin> can i change motion.spindle-at-speed ?
[03:17:16] <penguin> motion.spindle-at-speed=342
[03:17:47] <SWPadnos> here's the manual page for motion, from the page I linked you to:
http://www.linuxcnc.org/docs/2.3/html/man/man9/motion.9.html
[03:18:55] <SWPadnos> here's something to ponder: anything you do in G-code will have a pause of up to 1 ms, since it's going to be done by the motion or IO controller, which run by default at a 1 kHz rate
[03:19:47] <penguin> then, i need to speed up the 1kHz rate
[03:19:50] <SWPadnos> so anything like S words, M62/M63, using another axis, some other M code, whatever else, will only update every 1ms by default
[03:19:55] <SWPadnos> yes, you probably do
[03:20:25] <penguin> what's tha name of this rate? (like servo rate, base rate)
[03:20:30] <SWPadnos> or, you need to make a HAL component that can stream data at "realtime rates", based on actual motion from the stepgen
[03:20:33] <SWPadnos> servo rate
[03:20:47] <SWPadnos> SERVO_PERIOD_NS is the ini variable
[03:20:59] <SWPadnos> note that if you set it too low, your PC will crash
[03:21:31] <SWPadnos> slightly before that happens (in terms of servo period settings), it will seem very sluggish
[03:22:08] <pcw_home> Is realltime load (% of CPU time) readable anywhere?
[03:22:34] <penguin> ubuntu have a cpu monitor
[03:22:38] <SWPadnos> I don't think it is actually
[03:22:43] <pcw_home> that would be a good guide of how far to go
[03:22:48] <cradek> halcmd show threads?
[03:22:54] <SWPadnos> you can see the time each thread takes (last and max) with halcmd
[03:23:00] <cradek> don't those give the total execution time ... yeah that
[03:23:15] <SWPadnos> and you can watch how it changes with something like "watch halcmd show thread"
[03:26:12] <penguin> we want rastering in EMC 2.4.1
[03:26:15] <penguin> :)
[03:26:29] <SWPadnos> patches gratefully accepted :)
[03:30:06] <penguin> i don't know if mach3 could do the job
[03:30:11] <penguin> :o
[03:30:37] <penguin> can i say mach3 here?
[03:30:41] <penguin> is a bad word?
[03:30:43] <SWPadnos> if you write some VB code, it probably can do it
[03:30:53] <SWPadnos> it's allowed, but irrelevant
[03:40:55] <zsircusr> hah the internet is cool
[03:41:14] <zsircusr> zsircusr is now known as Valen_mobile
[03:41:28] <Valen_mobile> thats better
[03:42:27] <Valen_mobile> nice having a woman who can drive a 4 liter straight 6 manual transmission so i can install irc on my phone
[03:43:00] <Valen_mobile> so what was the verdict on xyza?
[03:43:19] <penguin> programmers dont have womans
[03:44:25] <Valen_mobile> thats ok i'm a space scientist
[03:44:51] <penguin> i'm rocket science
[03:45:26] <penguin> and i have a message for you
[03:45:52] <penguin> xyza....
[03:45:53] <Valen_mobile> i just play a programmer on tv
[03:45:53] <Valen_mobile> so what do you think of the microstep to adjust a
[03:46:20] <Valen_mobile> hmm variable signal might not help irc
[03:47:02] <penguin> maybe HAL programming the servo period can be the solution
[03:47:10] <penguin> damn
[03:47:54] <Valen_mobile> sory missed that
[03:48:12] <penguin> maybe HAL programming the servo period can be the solution
[03:48:20] <penguin> rather than xyza
[03:48:46] <Valen_mobile> whats bad about it? its not ideal but its easy
[03:49:32] <penguin> it's easy, but i think the A axis have intertia, like Z
[03:50:08] <Valen_mobile> inertia is a property of mass, light has no mass
[03:51:00] <penguin> i mean, there is no difference controlling A or Z
[03:51:09] <penguin> so, the problem should be the same
[03:52:23] <Valen_mobile> z is a physical axis it needs to move qand as such needs to accelerate to do so
[03:53:14] <Valen_mobile> a is just a pwm out, it will go to full in proportion to the error between commanded and actual positions
[03:53:25] <penguin> A is a pwm out???
[03:53:46] <Valen_mobile> yes you make a a servo channel
[03:53:51] <penguin> i'm going to kill myself
[03:54:29] <Valen_mobile> assuming you use compatible hardware
[03:54:58] <penguin> then A and Z are not interchangeable
[03:55:28] <Valen_mobile> huh?
[03:56:35] <penguin> Valen_mobile, you change my life
[03:57:12] <Valen_mobile> i'm not guaranteeing any of this
[03:57:59] <penguin> can anyone confirm if the A axis is used for pwm?
[03:58:05] <Valen_mobile> do you have mesa or anything?
[03:58:19] <penguin> the hardware controller?
[03:58:23] <Valen_mobile> a is just an axis it can be step or pwm
[03:58:27] <Valen_mobile> yes
[03:58:49] <penguin> it's a chinese controller board, with step and direction
[03:59:33] <penguin> i feel so stupid
[03:59:38] <Valen_mobile> well that may be a problem
[03:59:47] <penguin> where?
[04:00:06] <Valen_mobile> i dont know if you can drive an axis pwm out in software
[04:00:48] <penguin> in the stepconf wizard there is pwm generation in any pinout you want
[04:03:24] <Valen_mobile> outside my knowlage. that
[04:04:09] <Valen_mobile> ask swpaqdnos or someone
[04:04:15] <penguin> every space scientist know that
[04:04:23] <penguin> you should be shame
[04:04:33] <penguin> ;)
[04:06:24] <Valen_mobile> well i"m at the shops now
[04:08:10] <Valen_mobile> nooo candle shop escape toirc
[04:12:05] <penguin> SWPdanos?
[04:12:13] <penguin> roger that?
[04:34:49] <penguin> optic
[04:34:53] <penguin> old friend
[04:35:25] <penguin> you are not a space scientist, right?
[05:03:04] <Valen_mobile> mzormic 6 cores? new cpu?
[07:20:38] <Valen_mobile> ikea should come with mobility scooters
[07:24:00] <archivist> look for the escape routes so you can shorten the walk around ikea
[07:24:36] <Valen_mobile> yeah we do that, thing is missus wants stuff everywhere
[07:25:42] <Valen_mobile> also we were hungry on the way in so we wentt to the restarunt first rather than in the middle
[07:26:03] <Valen_mobile> good meatballs though
[07:26:17] <Valen_mobile> and an awesome almond cake
[07:26:45] <archivist> I dont go for food just bookshelves
[07:46:31] <Valen_mobile> we got a mirror
[07:46:37] <Valen_mobile> and blankets
[07:46:52] <Valen_mobile> and one of those almond cakes
[09:17:10] <MattyMatt> I find my food the same place I find my bookshelves. in a tree
[09:18:36] <MattyMatt> when I lived in yorkshire, the local sainsbury's had an excellent black cherry tree outside. everyone was saying "ooh you shouldn't eat strange berries"
[09:18:57] <MattyMatt> morons, they were biant black delicious cherries
[09:19:05] <MattyMatt> ^giant
[09:20:09] <MattyMatt> the adjoining car park had a red cherry tree too. I filled my boots
[09:20:57] <MattyMatt> 3 pound a punnet inside the shop, for lesser ones
[09:42:43] <jalonsor1> hi, any one knows which code is used for a lathe rotor positioning? i would like to rotate in N segments of circumference and between each segment apply a milling tool work. Thank you very much.
[09:43:25] <jalonsor1> sorry, code=Gcode verb
[10:23:52] <MattyMatt> isn't it one of the rotation axes? A,B or C?
[11:09:29] <JT-Dev> I have the pokeys55 plugged in and when I do a less /proc/bus/input/devices I see two
[11:09:39] <JT-Dev> one has input0 and one has input2
[11:10:06] <JT-Dev> Phys=usb-0000:00:0b.0-7/input0
[11:10:17] <JT-Dev> Phys=usb-0000:00:0b.0-7/input2
[11:12:23] <JT-Dev> http://pastebin.com/2qSAmSdn
[11:12:37] <tobs> I want to mill thelinux pinguinfromthe example file 3D_Chips.ngc but itdoesn't fit in my limits. Soi think I have to scale thegcode. Anybody an idea how to do it?
[11:14:01] <JT-Dev> when I try and load it I get this error
http://pastebin.com/NZCDTGwx
[11:14:43] <micges> tobs: 3D_chips is not sclable, you must do it by hand or write simple program to do it
[11:15:20] <JT-Dev> morning micges
[11:15:40] <JT-Dev> do you know if anyone has connected the PoKeys55 to EMC?
[11:15:42] <morficmobile> 'morning
[11:15:46] <micges> hi JT-Dev
[11:15:47] <tobs> ok i see. I thought there is a way to implement the scale to thefile :-)
[11:16:23] <JT-Dev> tobs: some files are created with a scale some are not
[11:16:33] <morficmobile> JT-Dev: do you have your computer in the front close to the screen, or in the back, vga/dvi-d running to the front?
[11:16:35] <micges> JT-Dev: no but I think there was discussion about it
[11:17:10] <micges> tobs: simpliest is to define scale at beginning (#30 = 0.9)
[11:17:14] <JT-Dev> morficmobile: I'm not sure what your asking
[11:17:32] <micges> and then multiply each coords by that variable
[11:18:04] <tobs> Doyou know where i can get some examples with scale options other than the pinguin to test 3d milling?
[11:18:10] <JT-Dev> I have a PoKeys55 now
[11:20:05] <micges> tobs: axis splash gcode
[11:20:42] <micges> somewhere in usr/share/axis
[11:22:54] <morficmobile> JT-Dev: i'm wondering about the length of the video cables with the computer mounted in the back, and lcd mounted on front
[11:23:07] <JT-Dev> on my lathe?
[11:23:14] <morficmobile> si senor
[11:23:33] <JT-Dev> ah, I'm just barely awake lol
[11:24:06] <JT-Dev> my monitor hangs out the front and sits on the saw horse for my chop saw at the moment lol
[11:25:00] <JT-Dev> most of the cables I've seen are 3' to 4' long
[11:25:02] <morficmobile> although it is the least of my problems, the mori seiki is now completely taken apart, the ways are horribly rusted as if it sat in the open for a while, and i need to figure out a way to convince my boss to not try anything, to just get them done
[11:25:55] <morficmobile> JT-Dev: i was asking since boss likes the idea of mounting computer in the large cabinet in back, and route vga/keyboard/mouse to front
[11:26:39] <JT-Dev> I'd check your cable lengths on that first
[11:28:15] <morficmobile> right
[11:33:06] <morficmobile> some cheating is possible since a KVM switch makes it all pretty long w/o much noticable loss, i'll find out
[11:37:20] <JT-Dev> micges: I found the discussion on the PoKeys55 and it is suggested that it might work with hal_input
[11:37:24] <JT-Dev> so far no luck
[11:37:53] <morficmobile> virtualbox gets dog slow with axis lathe sim :/
[11:39:18] <micges> JT-Dev: long vga and usb/ps2 cables ofter lead to noise problem here
[11:40:53] <morficmobile> while i watch virtualbox at a .5 fps kind of ride, couldn't tobs edit the code he wants to run and change every X somecoordinate and Y somecoordinate to a X [somecoordinate*#1] Y [somecoordinate*#1] where #1 would be assigned say .5 to scale it? tedious, sure :)
[11:41:12] <JT-Dev> I've had good luck with up to 12' of usb cable on my joypad but have never extended a vga or ps2 cable but I guess the environment has a lot to do with that too
[11:42:27] <morficmobile> micges: which is why i was asking, with all the currents inside a CNC especially
[11:42:48] <micges> I think here long usb cables caused strange keyboards disables
[11:42:51] <micges> and mouse too
[11:42:52] <JT-Dev> morficmobile: he could do a search and replace I think
[11:43:37] <JT-Dev> on the plasma I never run the plasma when I'm using the joypad so I might not notice any problems
[11:44:06] <micges> JT-Dev: could be
[11:44:15] <morficmobile> i would try some regex stuff on that, yes, not a regex buff, so i try not sound like i wouldn't sit there for a few refreshing my mind first
[11:44:59] <MattyCNC> cradek was right yesterday, I did have an extra G1 point deep in the acute angle :p
[11:45:17] <tobs> good point morficmobile, thanks
[11:48:54] <morficmobile> i wish i had a full day going over all the "oh i can do that in emc2's gcode?" items, but so far, if i do get to it, virtualbox runs so slow, there wouldn't be a way to run it
[11:51:53] <micges> morficmobile: gcode along with hal can do everything I need
[11:53:58] <morficmobile> micges: i mean playing with variables, o word loops, i know i can do a simple G71 OD roughing with an O word loop, but i would love to simulate it too :)
[11:54:57] <micges> morficmobile: you're on winblows ?
[11:55:31] <morficmobile> at work, yes, and i have ubuntu running in virtualbox
[11:56:12] <morficmobile> at home i'm on a non ubuntu linux, so ubuntu there too runs inside virtualbox, but that doesn't matter much as i don't get around to really doing much at all at home lately
[11:57:34] <morficmobile> load is 6.5 right now, and it took forever to get a new tab open in terminal to type top in and wait for that to load :P
[11:57:42] <micges> strange, here at work winxp on virtualbox on ubuntu 8.04 runs blazing fast
[11:58:18] <morficmobile> what kind of machine? guest extensions installed?
[11:58:34] <micges> I wonder why it doesn't in other way
[11:59:08] <micges> e5300 with 2gb ram ddr2
[11:59:28] <micges> no idea about guest extentions
[11:59:42] <micges> it's 8.04 rt system from linuxcnc.org
[11:59:58] <morficmobile> seems to relate to higher resolutions, i used to blame guest extensions, but now with higher res w/o guest extensions it acts just the same, and on 800x600, axis for lathe is squished
[12:01:32] <morficmobile> this is a P4 system, but i'd expect it to run virtualbox still quicker than it currently does
[12:01:39] <micges> me too
[12:02:04] <micges> check virtualbox settings, amybe you're missed something
[12:04:40] <morficmobile> trying to gracefully shutting down, so i don't lose my xorg.conf edit, if i was to just restore previous snapshot
[12:08:59] <micges> bbl
[13:54:24] <frallzor> all dead in the heat today? =)
[13:54:39] <frallzor> or well, hot here at least :P
[14:00:08] <JT-Dev> cool here
[14:02:39] <frallzor> hot hot hot here
[14:02:43] <frallzor> summer! :P
[14:02:54] <frallzor> clear blue sky and a good mood
[14:02:59] <morficmobile> too many tools to find, but i guess i can't justify a few thousand dollars worth of tools, just because i am no fan of finding the right size regrinds, it's not actually that warm in shop yet though
[14:03:02] <frallzor> and shitloads of stuff to do inside =(
[14:04:47] <pcw_home> cool and clear in sunny California (~8C)
[14:05:01] <morficmobile> 8C sounds nice
[14:05:11] <frallzor> around 23-24C here
[14:05:21] <archivist> 21 C here in sunny England
[14:05:37] <frallzor> sunny south of sweden :P
[14:05:56] <morficmobile> sunny and england are two words i do no associate usually, fog and england however i do ;)
[14:06:43] <frallzor> * frallzor is biting in a sour apple atm
[14:07:18] <JT-Dev> * JT-Dev is trying to figure out how to write a udev rule for a pokeys55
[14:07:20] <morficmobile> irc, the original twitter
[14:13:13] <JT-Dev> hmmm what's linux for delete in the command window?
[14:16:50] <DaViruz> rm
[14:16:54] <DaViruz> (remove)
[14:16:58] <JT-Dev> thanks
[14:20:15] <JT-Dev> at least I'm making progress I have a different error message now LOL SUBSYSTEM=="input", mode="0660", group="plugdev"
[14:20:27] <JT-Dev> No input device matching '"PoLabs"' was found (2 devices checked)
[14:21:06] <morficmobile> JT-Dev: to delete a dir and everything in it, you would have to add -r (recursive) and -f (force), but be careful, rm -rf / will indeed delete everything, so a rm -rf / home/machinist/tests would be fatal, i prefer to never try to rm absolute paths
[14:21:45] <JT-Dev> I just navigate over to the dir then do things
[14:21:52] <morficmobile> right :)
[14:23:25] <JT-Dev> that way I can ls and see what is there
[14:25:59] <morficmobile> a double tab would still show you what you remove w/o being there, it's the times not double tabbing to get the path when the /home/machinist/ tests woul dbe fatal :)
[14:27:05] <JT-Dev> Can not find -sec EMC -var NML_FILE -num 1
[14:27:06] <JT-Dev> No input device matching 'Pokeys' was found (2 devices checked)
[14:27:34] <cradek> did you try lsusb and see what it calls itself?
[14:27:40] <morficmobile> i love virtualbox on this machine, i run emc2 once, when i exit axis and start it again, the virtual machine locks almost solid, since stuff reacting in a few hours is no good, i consider it solid
[14:28:26] <JT-Dev> cradek: no, I didn't know about that one
[14:29:11] <morficmobile> my bad, could have asked you about that too :/ lsusb and lspci are great tools
[14:29:12] <JT-Dev> I see 4 things and only one has a name the card reader
[14:29:56] <cradek> unplug it and see which one disappears
[14:30:30] <JT-Dev> this one does Bus 002 Device 005: ID 1dc3:1001
[14:30:43] <morficmobile> i admit, seeing how many people run emc2 successfully w/o having much if any linux experience, is comforting ;)
[14:31:17] <cradek> JT-Dev: at the end of man hal_input, it shows an example based on ID. I think that might be what you want.
[14:31:38] <cradek> I think in your case, the vendor ID is 1dc3 and product ID is 1001
[14:32:07] <JT-Dev> reading it now
[14:32:36] <cradek> aha, lsusb -v says which is idVendor and which is idProduct
[14:33:34] <cradek> bbl, must find breakfast
[14:33:46] <JT-Dev> the idVendor is for the udev rule right?
[14:38:20] <morficmobile> as sluggish as it runs, at least i can now see "reload tool table" is grayed out when program is running, rather than asking about it, still annoying mouse is almost unusable once axis runs
[14:40:16] <JT-Dev> holy crap I got it to work!
[14:41:45] <JT-Dev> * JT-Dev wanders off now with a smile on his face to get the tractor out
[14:41:53] <JT-Dev> cradek: thanks for the tips
[14:46:49] <frallzor> how odd, anyone know if there is a limit on visa card what you can pay online with?
[14:47:00] <frallzor> *that
[14:47:03] <morficmobile> on a debit card there might be
[14:47:23] <frallzor> regular card, credit or such
[14:47:29] <frallzor> *no credit
[14:48:44] <frallzor> trying to order v-carve but it fails with both card and paypal for some reason
[14:48:58] <morficmobile> i know our debit mastercard trips if wife shops across town in frequent succession, and old visa debit card had a $500/day ATM limit, but not for purchases.
[14:49:23] <morficmobile> your bank would know why it fails, what protections you may trip with that purchase
[14:49:49] <frallzor> worked fine before, its odd that it fails with paypal too though
[14:56:05] <frallzor> oh well, bloody holiday too this weekend so of course no support =P
[15:04:30] <SWPadnos> frallzor, there may be a limit, but I have bought an $18000 scope online before, paying with a CC
[15:05:39] <frallzor> well this is odd then
[15:12:50] <frallzor> cant even use an E-card
[15:14:39] <SWPadnos> maybe the vendors authorization system is borked
[15:16:00] <frallzor> still, same issue with paypal
[15:18:52] <frallzor> and paypal is weird too, cant use the card since I believe they want me to add a code that wont show up when looking at account history :)
[16:01:59] <sealive> hi today i made a profiling on UREOL
http://www.youtube.com/watch?v=Ya-inU9soiI
[16:02:17] <sealive> How can i get rid of the Speeding up and down to the axis
[16:02:18] <frallzor> * frallzor might have figured out the mystery
[16:02:59] <sealive> this edge breakink is so noicy
[16:03:15] <sealive> someone can help me
[16:03:16] <frallzor> funky sounding machine =)
[16:06:34] <archivist> sealive, adjust your acceleration rate
[16:07:49] <sealive> archivist: lower or higher
[16:07:58] <archivist> higher
[16:09:42] <sealive> next test tomowow
[16:10:03] <sealive> BY
[16:26:39] <dgarr> tobs: scalable 3D_Chips:
http://www.panix.com/~dgarrett/stuff/3D_Chips.ngc
[16:29:57] <morficmobile> tobs long left
[17:01:58] <frallzor> Game Over
[17:02:00] <frallzor> I win
[17:50:44] <JT-Dev> Sweet! 0-255 in hal_input from a $9 pot and the PoKeys
[17:54:17] <cradek> neato
[17:54:50] <JT-Dev> yea, and it has 4 analog inputs for pots and a whole bunch of digital inputs that show up too
[17:55:06] <cradek> sounds good for a front panel
[17:55:09] <JT-Dev> playing with scale and I get what ever range I want
[17:56:16] <JT-Dev> that's the half hatched plan for this one a FO, SO, and MV pot plus some buttons for start, stop, pause, resume, etc.
[17:57:56] <morficmobile> nice
[17:59:19] <JT-Dev> http://imagebin.ca/view/LFf6_5H.html
[18:00:11] <cradek> that's a lotta buttons and things
[18:00:36] <JT-Dev> yea, and no inputs are used up on the 5i20
[18:01:19] <JT-Dev> that's about 1/2 of what is there
[18:01:41] <isssy> hi all
[18:01:58] <JT-Dev> * JT-Dev wanders off to take a nap now
[18:14:02] <morficmobile> looks like you could put it behind the panel and hook up all things on panel and pendant up on one pokeys55
[18:19:48] <frallzor> I won morficmobile :P
[18:24:30] <morficmobile> running emc2 with axis.ini in virtualbox, no problem, running emc2 with lathe.ini is SLOW
[18:24:42] <morficmobile> frallzor: how'd you tackle them?
[18:30:59] <morficmobile> boo, it's exiting my O100 while [] right away
[18:31:48] <frallzor> morficmobile research, their currency conversion was off
[18:31:58] <frallzor> so I had to put more money on the card account =)
[18:33:23] <archivist> they won, they got more money :)
[18:33:24] <morficmobile> yes! now the path looks right
[18:34:13] <morficmobile> got my fake G71 done in o word while loop, despite the sluggish virtualbox
[18:34:31] <frallzor> archivist nah, they got what they wanted =)
[18:34:46] <frallzor> but I had to pay more to give them the same =)
[18:34:55] <frallzor> currency conversion ftl
[18:35:57] <morficmobile> seeing X+ on the bottom of the screen is trippy
[18:36:22] <frallzor> I got software, I got wood, I got nothing to do :P
[18:36:54] <frallzor> my first client cant be served until I get the material either :P
[19:10:35] <morficmobile> i can't nest an o102 if inside a o100 while ?
[19:10:57] <frallzor> what does nest mean btw?
[19:11:06] <frallzor> saw the same term in the vectric forum
[19:12:15] <morficmobile> i mean use the O102 inside the O100 with nesting here
[19:12:49] <morficmobile> when you figure out how to fit as many parts/shapes on a sheet on a router, that's nesting too
[19:14:22] <morficmobile> w/o the O102, the loop runs but scraps the part, so i put a check after a calculation to set X to the minimum if the result of the calculation is smaller than minimum, going to see if i can modify the while condition instead
[19:17:54] <morficmobile> moving the calculation to the end should achieve the same thing, and add one calculation in front of the loop to not scrape the casting scale with our insert
[19:25:36] <frallzor> vectrics simulation is amazing
[19:25:46] <frallzor> evey mark down to the end
[19:29:45] <morficmobile> lol, i should have made a backup on this machine, the .ngc is now empty inside virtualbox
[19:32:49] <frallzor> http://pici.se/p/IIJcOIDgM/?size=fullsize is this nice or what? =)
[19:36:15] <JT-Dev> frallzor: did you carve that out?
[19:36:38] <frallzor> nah its just the simulation
[19:36:54] <frallzor> I love how it shows the quality of the cuts that good
[19:36:56] <frallzor> =P
[19:37:15] <frallzor> but that is my next project
[19:37:24] <frallzor> just need to get the measurements of the wood
[19:54:12] <frallzor> how sparse the activity is today
[19:54:31] <davidf> morficmobile, you can have an o102 if inside an o100 while.
[19:56:59] <morficmobile> davidf: thanks, i still worked around that because once i had the O102 if inside the O100 while, the virtual machine was really unbearable, and it had ran the O100 while by itself "fine"
[19:57:24] <davidf> 'K.
[19:57:46] <morficmobile> but good to know for later, when i have a computer to work with......
[19:58:49] <frallzor> lets show off some work!
[19:58:54] <frallzor> thats fun for all =))
[19:59:05] <davidf> Forgive the question, but did you have the o102 enif there? :)
[19:59:13] <davidf> endif...
[20:00:09] <davidf> SWPadnos, are you around today?
[20:03:10] <morficmobile> davidf: yes, it was there :)
[20:03:27] <morficmobile> fun, got a stock OD roughing cycle in a O100 while loop now
[20:04:02] <morficmobile> if only virtualbox was any faster
[20:05:00] <davidf> Is SWPadnos ever here on Weekends?
[20:06:39] <morficmobile> i *think* so
[20:08:10] <frallzor> he was before
[20:08:15] <frallzor> I reckon
[20:09:48] <davidf> O102 IF [ SWPadnos >=1]...
[20:10:02] <davidf> ...etc.
[20:10:10] <davidf> o102 ENDIF
[20:12:13] <morficmobile> i need to shut this machine down, i can't cop/paste, clipboard not accesible
[20:12:26] <Jymmm> C+A+BKSP
[20:12:29] <Jymmm> startx
[20:12:37] <Jymmm> (if enabled)
[20:13:12] <morficmobile> this is windows, and it seems virtualbox was hogging cliboard, but couldn't copy paste in guest either
[20:13:39] <morficmobile> could just /etc/init.d/gdm stop and start (worked, restart however didn't)
[20:14:51] <morficmobile> switching from gnome to icewm seemed to help a little to run lathe.ini, it was slow, but usable, unlike axis.ini which runs quick
[20:16:59] <davidf> bbl
[20:43:24] <alex_joni> morficmobile: try sim/lathe
[21:37:54] <Jymmm> sim/moneymachine is what I want to see!
[21:44:49] <SWPLinux> s!sim/!!
[21:48:44] <JT-Dev> I beat the insert into submission until it was low enough for the rear plugs to fit into the holes properly
[22:04:47] <frallzor> oh my, Ive spent way to much on my "business" :P
[22:09:00] <JT-Dev> sometimes you have to spend money to make money
[22:12:55] <frallzor> sometimes you just spend
[22:26:49] <frallzor> wonder where to store my wood, might be slightly warped due to warm moist weather today
[22:34:15] <mikeggg> how would I invert the functionality of the amp enable on a 7i37 ?
[22:34:30] <mikeggg> err 7i33
[22:50:55] <mike> mike is now known as Guest89884
[22:54:21] <Guest89884> Guest89884 is now known as mikeggg
[23:33:39] <davidf> mikeggg, what's a 7i33?
[23:44:43] <morfic> davidf: mesa daughterboard for analog servo control
[23:47:05] <davidf> Knew I shouldn't have asked. :) Thanks.
[23:48:26] <morfic> i would have pasted a link, but mesanet.com is not responding for me right now, CYA, making sure i don't ever so slightly say it wrong :)
[23:49:45] <morfic> * morfic loves o word while loops and variables and stuff
[23:58:30] <muale> hi all