#linuxcnc | Logs for 2013-10-13

[01:50:16] <JesusAlos> hi
[02:00:15] <_DJ_> moin
[02:03:12] <t12> heya
[02:03:24] <t12> finally probed the comms from the mitsubishi encoder
[02:03:27] <t12> its somewhat confusing
[02:08:36] <t12> https://www.dropbox.com/sc/5skqj6nm3oc7c3m/vyunJ2h_oD#/
[02:08:56] <t12> + and - for MR, MRR, MD, MDR, and the subtracted trace
[02:09:04] <t12> One of those is MR, MRR the other MD, MDR
[02:09:23] <t12> both lines seem to have encoder position data on them
[02:09:40] <t12> one set of pulses seems to have a preamble
[02:10:03] <t12> data always seems to be fixed data, lsb -> msb position data, fixed data, checksum (assumed)
[03:13:11] <pascal> Guten Morgen zusammen, bin einsteiger und möchte eine Fräse mit zwei x-achsen, einer y und einer z achse konfigurieren. Die Motoren konnte ich bereits einstellen mit stepconf wizard, aber wie geht es nun weiter?
[06:26:20] <jthornton> .quantize
[06:27:54] <archivist> quantisation error
[06:28:40] <archivist> the posh word for my periodic error
[06:29:17] <jthornton> I'm learning about python decimal, which does not have the rounding errors of float
[06:30:21] <archivist> I updated http://www.archivist.info/cnc/screw_error/ this morning with some more numbers "proving" where the error is from
[06:32:27] <archivist> we recommend decimal in #mysql because you get back what you put in
[06:33:20] <jthornton> yes, decimal is much more friendly and predicable
[06:34:53] <archivist> and the good old resolution v accuracy...which noobs get wrong
[06:35:04] <jthornton> aye
[07:57:16] <archivist> what kind of "glass" is used for distance standards like 1"
[08:01:47] <berny83> hi guys, i'm trying to run linuxcnc but I've two main issue that have stop my work, are you so kindly to help me in solving the two issues?
[08:04:32] <archivist> just ask the real questions
[08:05:09] <berny83> first of all i'm trying to set up homing with home_use_index (indexpulse + mechanical switch), I have a problem while performing homing: the home procedure works fine but when the index pulse has been detected, the axis does not stop but it travel for about 25/30 mm towards positive coordinates (i have set home_offset = 0 and home = 0)
[08:05:57] <berny83> it seems that the overshoot travel depens on the home_final_vel value
[08:06:30] <berny83> the greater is home_final_vel, the greater is the overshoot
[08:07:32] <archivist> have you set your acceleration/deceleration very slow
[08:07:34] <berny83> Practically i would the axis to stop on the index pulse (home = 0 and home_offset = 0)
[08:08:05] <berny83> acceleration is about 3000
[08:08:33] <berny83> that seems to be enough while jogging
[08:12:09] <berny83> the other problem i've is about stability of the system, often, while drivers are enabled, I get "contact on limit 0" without a real contact... monitoring the signal with halscope I discovered that a random true state occur (length about 0.5 ms) and cause the machine to toggle drivers enable status
[08:12:39] <berny83> I use mesa 5i23 with hostmot2 fpga
[08:13:17] <archivist> you need to fix random signals, make sure pulled up/down properly and no ground loops etc
[08:13:18] <berny83> so PCI board with PCI power
[08:15:08] <berny83> previous installation gives me this problem randomly (1 or 2 times/day); yesterday, a new installation gives me the contact on limit 0 continuosly (20/30 times on a single morning)
[08:15:40] <berny83> sometimes also contact on limit 1 has occurred
[08:16:31] <berny83> do you think it's due to electromagnetic noise?
[08:21:30] <archivist> bad contact,noise,ground loop, bad/wrong pull up/down, you have to diagnose
[08:22:00] <archivist> I would be using a real scope to do that
[08:22:07] <berny83> you have said "make sure pulled up/down properly and no ground loops etc", jave you any link where I can read something about it? I've no feeling with electical components
[08:23:13] <archivist> also did you follow the guide/best practices in the mesa manual for pull ups
[08:23:14] <berny83> I simply connect mechanical switch to 5i23 GPIO (with jumpers on 3.3V)
[08:23:39] <archivist> how good is the switch too
[08:23:54] <berny83> OMRON microswitch
[08:24:32] <archivist> while a reasonable maker, I would want to test/measure the contact
[08:25:03] <berny83> but i get that problem also soldering the cable (so I think is not due to bad switch)
[08:25:23] <archivist> never assume
[08:25:37] <berny83> :)
[08:26:02] <archivist> I was testing a contact a week ago and it needed some current to wet the contacts
[08:27:01] <archivist> 3k ohms on a meter, but 6volts and some current one could light some LEDs through it
[08:27:03] <berny83> you are right but if I take off the switch and join the two wires..
[08:28:11] <berny83> have you any experience with pci power supply?
[08:29:43] <berny83> CIT from MESA manual : Pullup resistors are provided for all I/O pins, These pullups can simplify interfacing
[08:29:43] <berny83> to open collector devices such as mechanical switches, OPTO isolators and OPTO
[08:29:43] <berny83> interrupters. Pullup voltage can be selected to be 5V or 3.3V on a per connector basis.
[08:29:43] <berny83> When the pullup voltage jumper is in the ‘up’ position, 5V pullup voltage is selected, when
[08:29:43] <berny83> the jumper is in the ‘down’ position, 3.3V pullup voltage is selected.
[08:31:25] <archivist> get your meter on the volts range across the switch, measure when open and closed
[08:32:10] <berny83> ok
[08:32:24] <berny83> i'll try it
[08:34:17] <berny83> i'm very sad because these problems, they are too important...
[08:51:23] <berny83> are anyone here using 5i23?
[08:52:22] <berny83> I'm searching for extra-info (manual and integrator manual are not exaustive for me)
[08:56:18] <archivist> there are plenty using mesa cards, just ask the real questions in IRC then anyone can answer
[08:59:41] <pcw_home> If you connect field wiring (switches etc) directly to 5I23 inputs, expect to see noise (inputs work to 100MHz or so)
[09:04:44] <berny83> ok, and what would be the best practice in order to avoid noises?
[09:05:52] <pcw_home> Thinks you can do:
[09:05:54] <pcw_home> 1. Use a daughter card thats intended for this purpose (7I37TA, 7I42TA, 7I70 etc)
[09:05:55] <pcw_home> 2. Put a small capacitor across the 5I23 input and ground
[09:05:56] <pcw_home> 3. Use the HAL debounce component
[09:05:58] <pcw_home> 4. Shield switch wiring
[09:06:56] <berny83> ok :) now I have some ways to investigate!!
[09:07:57] <berny83> thanks, I am a newbie in electronics!!
[09:08:32] <berny83> and I've never had to do with electric noises
[09:08:57] <pcw_home> Well method 3 is software only :-)
[09:14:49] <berny83> I think I'll try it first of all!!
[09:14:54] <berny83> thanks again!!!!
[09:16:02] <berny83> I'm going to try it now!! Bye bye all!
[09:25:19] <kwallace> Since there is no traffic. This looks like it should work but I get no spark: http://www.wallacecompany.com/KDX250/cdi_signals-1a.png I'm wondering if the voltages are too low, weak magnets?
[09:34:34] <pcw_home> How is it intended to work? looks like you would only get 20V
[09:34:35] <pcw_home> on the spark coil primary, about 10x too low for normal coils
[09:37:47] <pcw_home> Normal magnetos store inductive energy in the spark coil and interrupt the current
[09:37:49] <pcw_home> to generate the spark. Capacitive discharge types need a couple hundred volts normally
[09:41:17] <kwallace> That's why I'm wondering if the magnets are weak, but I'm not sure since I didn't record the voltages when the bike was running.
[09:42:05] <pcw_home> 20V seems really low
[09:42:21] <kwallace> I put in new stator coils a few years back and they have reasonable resistance.
[09:45:29] <archivist> I am a bit surprised at 1n4007 in that circuit, not the fastest devices
[09:45:51] <kwallace> Around 170 ohms power coil and 70 trigger. Even the trigger voltage seems low, since the schematics I have seen usually have current limit resistors.
[09:46:22] <pcw_home> might measure the open circuit power coil output to see if theres a load problem
[09:47:03] <kwallace> The upper two traces are open circuit.
[09:47:32] <archivist> some ignition coils could be damaged if run without the spark gap in place
[09:48:20] <pcw_home> 170 ohms sounds pretty high, like its intended to genarat a high voltage (as you would expect)
[09:48:50] <pcw_home> generate
[09:49:30] <kwallace> The upper power trace peaks at about 25 Volts and is measured with the coil wires connected only to the scope.
[09:50:04] <pcw_home> kick starter? maybe you are getting old and slow :-)
[09:50:46] <archivist> close the plug up a bit
[09:52:05] <kwallace> I turned the rotor with a socket and a bit brace as fast as I could turn it.
[09:53:32] <archivist> battery drill
[09:53:35] <pcw_home> whats the voltage rating on the capacitor
[09:54:05] <pcw_home> or is this a potted module :-(
[09:55:00] <kwallace> The circuit is homemade based on what I found on the Internet. The cap is rated for 600V.
[09:55:28] <kwallace> http://users.rcn.com/cfharris/minibikeignition.html
[09:56:44] <kwallace> http://homemadecircuitsandschematics.blogspot.com/2011/12/how-to-make-capacitive-discharge.html
[09:59:07] <archivist> I have a bunch of early Lucas circuits here but were for car ignition http://www.collection.archivist.info/searchv13.php?searchstr=lucas+opus
[10:01:39] <kwallace> I'll need to bookmark that link, thank you.
[10:04:01] <CaptHindsight> the PIC should be fast enough to make an MSD (multiple spark discharge) so you can squeeze a bit more more out of that engine
[10:04:33] <kwallace> I think I'll remove the rotor and try to excite the power coil with another magnet or coil to see if I can get the voltage up. If that works, I'll need to figure out how to repair or replace the rotor.
[10:06:09] <kwallace> CaptHindsight: I was hoping to restore what I had to prevent another long project which doesn't seem to be happening.
[10:07:43] <kwallace> Another issue, I nearly killed myself the last time I rode the bike.
[10:08:30] <pcw_home> A rare earth magnet ought to liven it up a bit
[10:10:02] <pcw_home> dont end up in the Honda ward...
[10:10:50] <archivist> I am reminded of the knight in moty python saying its just a flesh wound
[10:12:58] <pcw_home> i gave up riding about 15 years ago
[10:13:15] <CaptHindsight> kwallace: just be really careful around the high voltage end of the coil, I've had arcs go through my hands leaving burns on opposite sides
[10:16:23] <berny83> pcw_home, debounce component seems to be what I was searching for. No more "crazy" contacts up to now!
[10:17:02] <berny83> My 50% of the problem seems to be solved!
[10:18:01] <pcw_home> Yeah the raw FPGA inputs are a bit too fast unless you have some filtering
[10:20:10] <berny83> Now I have only the homing issue... i.e. when i perform homing procedure (mechanical switch + servo index pulse) the axis does not stop on the index pulse (I've set HOME = 0 and HOME_OFFSET = 0) but it goes forward (it seems to go forward until the original position has been reached..)
[10:21:06] <berny83> Sure, I note it, and I have payed it with some nights at work!!! :D
[10:24:30] <pcw_home> have you looked at this:
[10:24:31] <pcw_home> http://www.linuxcnc.org/docs/2.4/html/config_ini_homing.html
[10:24:57] <kwallace3> Don't ignore proper cable terminating and filtering. Most input impedances are high and very easy to induce a noise onto.
[10:25:46] <berny83> ok, i know that link
[10:26:09] <berny83> and i read it more than one times
[10:26:32] <pcw_home> also you should verify tha the index inputs work properly
[10:26:37] <pcw_home> that
[10:26:39] <berny83> I try to better explain my honming issue... :) suppose I switch on the machine and the X axis is positioned at half stroke, I perform the homing and the axis come back exactly to half stroke
[10:28:20] <berny83> the only thinghs I've not understand are velocities sign, if i put serachvel positive, cnc drive the axis toward the + limit, opposite to the home position
[10:29:02] <berny83> i'm trying to configure cnc in order to home with the 3th scheme
[10:29:52] <berny83> coming back to touch the mechanical home, then invert direction and stop on the first index pulse
[10:30:19] <berny83> what is wrong in my homing procedure?
[10:31:20] <pcw_home> I would get homing to limit swiches only working first
[10:31:21] <berny83> if I would verify index pulse to work properly, what kind of test could i perform?
[10:31:37] <kwallace3> What do you use for the index sensor? Is there a sensor on the slide and the screw?
[10:32:26] <berny83> no, i use the pulse of the encoder on the back side of the motor
[10:32:28] <pcw_home> unlink index enable from motion, manually setp index enable and rotate shaft
[10:32:42] <berny83> i can get that signal by the drive
[10:33:07] <pcw_home> and verify that index enable is always cleared at the index position
[10:33:12] <pcw_home> bbl
[10:33:51] <berny83> i use delta servo
[10:35:21] <berny83> i've not fully understand your suggested test
[10:35:35] <berny83> i've to unlink index pulse wire??
[10:35:42] <kwallace3> Typically the slide has a rough index which can only produce one index pulse for the entire travel. This is coupled with the screw or motor index, which will produce an index every revolution.
[10:36:30] <berny83> yes, i think i'm homing following this concept
[10:37:21] <berny83> the index on the slide is a mechanical switch connected to home-x hal signal
[10:37:37] <kwallace3> In HAL there is a link between the motion module's index enable and your index sensor signal.
[10:38:07] <berny83> while the other is the axis.0.index-enable
[10:38:21] <berny83> yes sure
[10:38:24] <kwallace3> I think PCW wants you to remove that link and set the enable by hand with setp.
[10:39:15] <kwallace3> I think this will force motion to look for your index.
[10:39:21] <berny83> net x-index-enable axis.0.index-enable hm2_5i23.0.encoder.01.index-enable
[10:39:51] <berny83> 01 is beacuse I have inverted the two encoder wires (x with y)
[10:40:59] <berny83> what kind of command i have to write for example?
[10:41:01] <kwallace3> I'm not too familiar with the mesa setup and homing so I'm not much help without taking time out to study it.
[10:41:30] <berny83> ok, thanks anyway!
[10:41:43] <kwallace3> You can use setp with halcmd in a terminal.
[10:41:47] <berny83> you all are more and more experts than me
[10:42:50] <kwallace3> You can start LInuxCNC then open a terminal and start halcmd.
[10:43:43] <berny83> yes yes i kown it a bit
[10:45:56] <berny83> anyway the cnc seems to get the index because when i homing it hit the mechanical switch, then serach for index pulse (I can say it because i set latch vel very low and i see very well the difference with final vel) and take the pulse. Then instead of stop, it go away with home_final_vel
[10:47:59] <kwallace3> Have you set up HALscope to look at the axis motion to see if the axis backs off the index after finding it?
[10:50:31] <kwallace3> I think the the motion should search for the index at a moderate rate, hit the index, back off, then slowly find the index again. You should be able to see this on HALscope.
[10:50:36] <berny83> yes, the axis get the index
[10:51:18] <kwallace3> But do you see the proper sequence and directions?
[10:51:56] <berny83> yes, but you say the axis should get index twice?
[10:52:22] <berny83> from the scheme i have understand that axis get the index one time only
[10:52:40] <berny83> after hitting the mecanical switch
[10:53:58] <berny83> when i open the axis (software) x, y and z are in 0,0,0. actually the machine could be whereever in the work volume, ok?
[10:54:24] <berny83> the 0,0,0 shown by the axis is obviously wrong
[10:54:46] <kwallace3> My homing looks twice. Once to get close, then again to get to get the accurate location.
[10:55:23] <berny83> I homing the axis (now i'm trying with only the X) and it perform the rigth procedure but at the end it come back to the original 0,0,0 position
[10:56:16] <berny83> and what values have you assigned to serachvel latchvel finalvel home and homeoffset?
[10:56:45] <berny83> because the procedure depends on them values (as write in the manual)
[10:58:56] <kwallace3> The values I set came from starting slowly, then increasing them until homing failed. I then backed off the values a bit for a safety margin. My homing turned out to be pretty slow.
[10:59:56] <kwallace3> It might be helpful to post your HALscope plot.
[11:03:41] <berny83> when it starts from 0,0,0 (machine just switched on) it goes back (e.g coordinate assume negative values like -10, then -100 then -200) and stop itself on the mechanical home switch (suppose at -200mm). then it set the coordinate to 0 and start searching for pulse (tipically after 3 or 4 mm it get the pulse). then, after getting the pulse, it reset coordinate to -200mm (the same at whitch it hits the mechanical home switch) so it
[11:04:39] <berny83> in other words it comes back to the original position (when machine was off)
[11:07:36] <berny83> from halscope I see that index-pulse has been get twice
[11:08:09] <berny83> after have hit the mechanical switch
[11:08:21] <archivist> but was the first on the way to the switch
[11:09:49] <kwallace3> You should get the first index going at a direction, then back off a bit (without hitting index), then get the index again going the same direction as the first.
[11:10:23] <berny83> it seems the first occur while the mechanical switch has been relased
[11:11:00] <kwallace3> Yes, that way it knows it has backed off.
[11:12:04] <berny83> ok, but why it comes back to half stroke??
[11:12:19] <berny83> it's unbelievable!! :)
[11:12:36] <berny83> anyone tell it to com back
[11:12:53] <berny83> I would it to simply STOP
[11:12:54] <berny83> :)
[11:13:04] <berny83> there
[11:14:54] <berny83> i've tried now to homing from a different position. It has performed the homing and then it comes back again to the original position!!!!
[11:15:48] <kwallace3> Does the homed symbol show up after the homing is done?
[11:17:16] <berny83> yes
[11:17:24] <berny83> it appear
[11:17:40] <kwallace3> In the ini file you can set up an offset home position, so after homing it will go to the index location plus the offset.
[11:18:17] <berny83> right
[11:18:31] <berny83> but offset is set to "0"
[11:18:31] <berny83> and home too
[11:18:51] <berny83> another thing is why i have to set searchvel negative and latchvel positive while all other users use opposite signs
[11:18:53] <berny83> ?
[11:19:58] <berny83> if i set searchvel positive the machine go to positive coordinates so it will never hit the switch
[11:20:57] <kwallace3> So, it seems LinuxCNC thinks it is homing properly, but the the index signals must be wrong. I think you are getting different index locations, you should only get an index at one location.
[11:22:03] <kwallace3> Look at your HALscope while jogging across the axis and see if index shows up more than once.
[11:22:50] <berny83> ok
[11:23:59] <berny83> no index shown up while jogging
[11:24:36] <kwallace3> Strange.
[11:27:58] <kwallace3> I'm looking at my config to see where the encoder index and home sensor go.
[11:29:25] <berny83> ok, thanks a lot!!
[11:55:41] <kwallace1> It looks like the home sensor is linked to axis.0.home-sw-in and the encoder index to axis.0.index-enable. The link up of the two must be inside axis or motion module. I'll need to go out to the shop to see where it goes from here. BBL
[11:57:09] <berny83> thanks again
[11:57:27] <berny83> i have the same setup
[11:57:27] <berny83> .... :(
[11:57:40] <berny83> i'm beeing crazy!
[11:58:48] <berny83> no solution to the problem.. and internet does not have suggestion for me
[11:59:42] <berny83> I can perform the home but in the end it moves again on the original position where it put the "0" coordinate
[12:00:04] <berny83> it's very strange
[12:27:08] <IchGuckLive> hi all B)
[12:28:19] <berny83> have you ever tried to connect only the index pulse of the encoder without connecting other wire (A and B channels)?
[12:29:26] <IchGuckLive> its good at spindel only RPM
[12:29:26] <berny83> i work in a pseudo"open loop), servo drived as stepper with pulse/dir
[12:30:00] <berny83> i know but I'm trying to make this configuration on the X Y axes
[12:30:17] <IchGuckLive> berny why you can get sutch a good performance on realservo
[12:30:34] <berny83> but homing procedure became crazy and it is useless
[12:30:43] <IchGuckLive> berny where are you from USA europ asia
[12:30:53] <berny83> europe
[12:31:04] <IchGuckLive> im in kaiserslautern Germany
[12:31:12] <berny83> delta drives
[12:31:18] <berny83> nice to meet you!
[12:31:36] <berny83> do you know delta?
[12:32:01] <awallin> berny83: did you read http://www.linuxcnc.org/docs/html/config/ini_homing.html
[12:32:19] <berny83> yes, a lot of times
[12:32:56] <berny83> i could explain you the behaviour of the cnc
[12:33:29] <berny83> when i open the axis (software) x, y and z are in 0,0,0. actually the machine could be whereever in the work volume, ok?
[12:34:03] <berny83> the 0,0,0 shown by the axis is not home position ok? they are now relative to a random position of the machine
[12:34:17] <CaptHindsight> IchGuckLive: I seem to see more high tech and software co's from your area and south to Freiburg. Is that sort of the high tech belt of Germany or just coincidence?
[12:34:18] <berny83> I homing the axis (now i'm trying with only the X) and it perform the rigth procedure but at the end it come back to the original 0,0,0 position
[12:35:14] <IchGuckLive> CaptHindsight: no its the way it is in germany
[12:35:55] <IchGuckLive> berny homeoffset is the gole not home
[12:36:40] <berny83> what does it means?
[12:37:31] <berny83> i start from a random position when i turn on the machine, with homing I suppose to reach a known position (the 0,0,0 origin of the machine)..
[12:37:32] <berny83> is it wrong?
[12:37:55] <IchGuckLive> you need to drive your mashine away from home switch witch is your index pulse
[12:38:11] <IchGuckLive> pulse index + homeswitch is the hoome
[12:39:03] <berny83> yes, the axis travel to hit the mechanical switch with searchvel velocity and then get the indexpulse with latch velocity
[12:39:12] <berny83> but it does not stop there!
[12:39:28] <berny83> it continue travelling to the original position!
[12:39:59] <berny83> and i can't explain to me why...
[12:40:56] <berny83> i don't know the reason for this last travel (performed at home_final_vel as if it was an home_offset)
[12:41:06] <berny83> but home = 0 and home_offset = 0 too
[12:42:06] <IchGuckLive> shoudt not be the same
[12:42:48] <IchGuckLive> get home -5mm and home 0
[12:43:10] <IchGuckLive> if your switch is at negativ X
[12:44:08] <berny83> yes, my switch is in the negative X direction
[12:44:18] <IchGuckLive> berny83: on the axis in the ini HOME_USE_INDEX = YES
[12:44:21] <berny83> i've an index pulse every 5mm
[12:44:33] <berny83> yes i do it
[12:45:06] <berny83> if i set "NO" homing occur with only mechanical switch (and works fine!)
[12:45:51] <berny83> if i set it to "YES" axis get the pulse but does not stop on it!
[12:47:57] <IchGuckLive> there is no stop
[12:48:32] <IchGuckLive> it only sets the value of homeofset to the DRO and trevels towards home
[12:48:37] <berny83> it stops on the original position
[12:48:52] <IchGuckLive> as it shoudt do
[12:49:13] <berny83> but home_offset is zero
[12:49:23] <IchGuckLive> as it shoudent be
[12:50:11] <berny83> so why axis does not stop on pulse but come back to the original position (an put there the axes origin)
[12:50:26] <berny83> why you say that?
[12:50:47] <IchGuckLive> berny did you looke at page 24 in the integreader manual
[12:51:11] <IchGuckLive> trvel means a t least 2 steps
[12:51:40] <IchGuckLive> berny are you german ?
[12:51:41] <CaptHindsight> http://www.bunniestudios.com/blog/?p=3110 Form1 teardown (SLA 3d printer using 405nm bluray laser and cheap galvos)
[12:51:55] <berny83> sorry?
[12:52:13] <IchGuckLive> language of country you are in
[12:52:34] <IchGuckLive> CaptHindsight: you can get this for 10USD
[12:52:52] <IchGuckLive> as there are som tray loose blue rays
[12:53:27] <berny83> no, i'm italian
[12:53:37] <IchGuckLive> ok
[12:53:48] <berny83> what means 2 steps?
[12:54:02] <IchGuckLive> http://wiki.farmbot.it/Welcome
[12:54:43] <IchGuckLive> berny83: there needs to be a travel space between home and homeofset if you use index
[12:55:02] <IchGuckLive> it simply can not be the same number
[12:55:14] <berny83> why?
[12:55:38] <CaptHindsight> heh, the Form 1 also uses a STM32 32-bit ARM Cortex-M3. Why does everyone want to reinvent the wheel so often?
[12:56:32] <andypugh> I think with index you can have them in the same place, the slow back-off move should continue until the switch is released, and then carry on until the index.
[12:56:53] <berny83> yes
[12:56:54] <kwallace2> I just tried my home, it starts at home, moves quickly off home and encoder index, moves slowly to trip home , then encoder index and stops.
[12:56:55] <berny83> exactly
[12:57:01] <andypugh> I do wonder if it isn't seeing the index, and is carrying on and than giving up.
[12:57:09] <berny83> but then it mus stop on pulse
[12:57:28] <andypugh> There is a final rapid move to the home position.
[12:58:08] <IchGuckLive> andypugh: thats what i try to fid out by home 0 homeofset -5
[12:58:16] <kwallace2> Mine moves slowly to home then index.
[12:58:18] <berny83> yes, but the home position for my emc is the original one, not the position written in the in file (0)
[12:58:35] <andypugh> If you had home as zero and home offset of (total travel / 2) then you would expect to see what you are seeing, but I don't thnk that is your setup.
[12:59:05] <kwallace2> How far and fast is the last move?
[12:59:27] <berny83> the last move is at home_final_vel velocity
[12:59:47] <kwallace2> How far?
[12:59:48] <andypugh> It might be interesting to halscope the home-state pin.
[13:00:10] <IchGuckLive> im off by
[13:00:19] <berny83> do you mean home-x?
[13:01:21] <kwallace2> How far does x move on the last move?
[13:03:03] <berny83> it return in the original position that had when the machine was off
[13:03:42] <berny83> if i turn on the machine with the axis at half stroke, after homing axes return at half stroke
[13:04:02] <andypugh> There is a axis.N.home-state parameter that you may be able to halscope to see what is going on.
[13:04:16] <kwallace2> Okay how far does each move take? Is it less than 5mm?
[13:04:39] <berny83> no, much more
[13:05:34] <berny83> axis.0.homed and axis.0.homing
[13:05:42] <kwallace2> andypugh: Is there a way to record a HALscope Roll?
[13:05:45] <andypugh> The meaning of the home-state pin is here: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/motion/motion.h;h=435eac7e80a1bc439555f73db240848079ab719a;hb=HEAD#l403
[13:05:45] <berny83> which one?
[13:06:04] <andypugh> kwallace2: Yes, you can save the trace from the file menu (IIRC)
[13:06:42] <kwallace2> My homing doesn't fit in the normal capture time.
[13:07:25] <berny83> my too
[13:07:45] <andypugh> kwallace2: You can change the sampling period to be every N thread cycles to record for longer
[13:08:06] <kwallace2> Cool, I'll look.
[13:09:15] <archivist> andypugh, what was the "have you got a slip" comment about last night ?
[13:09:16] <andypugh> The button that says something like "4000 samples in 4 seconds" can be pushed to change the numbers
[13:09:41] <kwallace2> Ah, in Multiplier.
[13:10:20] <andypugh> archivist: You can use slip gauges to extend the range of your DTI (or you could offset the measurements by a known amount, to see if the sawtooth is measurement device or machine
[13:11:14] <archivist> andypugh, I know the source of the saw tooth, its stepper frequency related
[13:11:25] <berny83> guys, i've to go to dinner, thanks a lot to all of you! i will back soon
[13:11:47] <archivist> andypugh, I updated that page with more info
[13:20:31] <kwallace2> Here is my HNC homing: http://www.wallacecompany.com/machine_shop/LinuxCNC/Screenshot-HAL%20Oscilloscope.png
[13:21:17] <archivist> he just fell off irc
[13:22:16] <kwallace2> Okay.
[13:25:55] <Tom_itx> hope he had his chute open
[14:44:42] <andypugh> kwallace2: I am going to guess that that was not the first home?
[14:47:58] <kwallace2> andypugh: How so?
[14:48:36] <andypugh> Position-fb hits 0 exactly at the index. I think that you would normally see a step-change at index.
[14:50:23] <kwallace2> Actually, I had done several at that point, but more often than not, the carriage is at home when I power up.
[14:58:41] <kwallace2> andypugh: Better? http://www.wallacecompany.com/machine_shop/LinuxCNC/Screenshot-HAL%20Oscilloscope-1.png
[14:59:03] <andypugh> Aye that is more like what I woud expect to see.
[14:59:32] <andypugh> Though there is no rapid-to-home?
[15:02:31] <kwallace2> The last move is slow.
[15:03:59] <kwallace2> Otherwise, it misses the narrow index.
[15:11:30] <berny83> is there anyone that can help me in homing troubles (mechanical switch + indexpulse homing)?
[15:11:42] <ries> berny83: what's the question?
[15:12:53] <berny83> i cannot perform homing correctly because the homing procedure is not correct, i give you an example
[15:13:21] <berny83> 1 - I switch on emc (axis) software
[15:14:17] <berny83> 2 - suppose axes could be anywhere in the working area (just supppose they are in 100,100 coordinates)
[15:15:53] <berny83> 3 - axis show me that coordinates are 0,0 and that there not be home (obviously it show 0,0 because it cannot know the actual position of the axes)
[15:16:27] <berny83> 4 - i perform homing (suppose i'm working only on X axis)
[15:16:50] <berny83> 5 - axis X go back looking for mechanical home switch
[15:17:09] <berny83> with searchvel velocity
[15:17:26] <berny83> 6 - axis X hits mech switch
[15:18:12] <berny83> 7 - axis X go forward (ascending X coordinates) looking for index pulse with latchvel velocity
[15:18:32] <berny83> 8 - axis X find index pulse
[15:18:52] <berny83> 9 - axis X "should" stop on index pulse
[15:19:49] <berny83> 10 - Instead stopping, axis X go to the original position (100,100) with home final vel velocity
[15:20:09] <ries> are you sure it's not a setting you told AXIS to go to?
[15:20:25] <ries> because , it doesn't have to stop, you can tell axis to move towards some position
[15:20:27] <berny83> the question is: why axis X does not stop on index pulse but travel to that position
[15:20:29] <berny83> ?
[15:21:00] <berny83> where that setting could be?
[15:22:06] <ries> I believe it's called HOME
[15:22:09] <berny83> I think it's not related to Home and Home_offset in ini file because they are fixed values while the travel is always different and equal to the original position..
[15:23:19] <berny83> I'm looking for someone who know how linuxcnc thinks while performs homing using index pulse
[15:24:20] <ries> so, you say if you move to X/Y (let's assume machine cordinates then) then after homing it will go back to 200,200 ?
[15:27:33] <berny83> not exactly ries, if you move to 200,200 axis show you coordinates 200,200; but if you then reboot the machine, axes are still in 200, 200 while axis show you 0,0. Ok? In this case if I perform homing, axes come back in 200,200 and emc (obviously) shows me 0,0 coordinates
[15:29:19] <Tom_itx> berny83, did you use the HOME_USE_INDEX var in the ini file?
[15:29:29] <Tom_itx> http://www.linuxcnc.org/docs/2.4/html/config_ini_homing.html
[15:29:30] <berny83> yes
[15:32:27] <ries> I have a hard time trying to understand what's going on… homing has been pretty much automatic for me so it's not something I take notice of, I frequently walk away while the machine does what it does
[15:33:03] <Tom_itx> is the home switch releasing before the index pulse is triggered?
[15:33:27] <Tom_itx> diagram 3 in that link
[15:34:40] <berny83> yes
[15:34:48] <berny83> it's that diagram
[15:35:23] <Tom_itx> i don't use an index pulse so i'm not much help
[15:39:33] <ries> berny83: on step 9 you assume that the axis should stop. Why is that? For me I need to get out of the because I need home a other location. Mind you, I did put all my switches in serial so I need to be ensured that I don't keep one sqwitch activated
[15:40:11] <ries> The onyl reason I can think of that what happens in step 10 happens is because you set HOME and HOME_OFFSET
[15:40:52] <berny83> but they are both set to zero..
[15:41:21] <pcw_home> If this is a step driven system and you use encoder feedback you must use velocity mode for the stepgens
[15:45:28] <ries> berny83: I wonder if it's related to this text in the doc : Note that even if this parameter is the same as HOME_OFFSET, the joint will slightly overshoot the latched position as it stops.
[15:45:43] <ries> Not sure of 100 is considered 'slighly overshoot' :D
[15:45:57] <berny83> sure :D
[15:47:29] <berny83> but the very strange thing is that the value (100 in this case) is not random but it is the position of the machine when it has been turned on
[15:51:55] <ries> well, Axis does remember some coordinates, even if you turn off/on the machine.. I'ts been a while since I setup my machine though, so I have a hrd time visualizing what's happening.
[15:53:18] <ries> berny83: try to set a HOME, see if that make a difference
[15:55:25] <berny83> no difference, the only difference is that when it get the home it set the value not to zero but to the HOME value
[15:56:08] <pcw_home> If this is a step driven system and you use encoder feedback you must use velocity mode for the stepgens
[16:00:36] <pcw_home> otherwise all bets are off for homing to index
[16:02:22] <andypugh> True, I have been assuming that this is a servo system.
[16:03:32] <andypugh> berny83: Can you halscope axis.0.homing-state and find out what the homing-state is during the return move?
[16:04:29] <berny83> sure, but not now, I'm at home, tmorrow morning at work i'll try
[16:05:02] <berny83> I have a servo system driven by step dir commands
[16:05:06] <pcw_home> are the stepgens in velocity mode?
[16:05:22] <berny83> how can I check that?
[16:05:32] <pcw_home> check your hal file
[16:06:46] <berny83> do you mean control type?
[16:06:57] <pcw_home> yes
[16:07:29] <pcw_home> also if you have the stepgen.fb connectd to _anything_ its wrong
[16:07:56] <berny83> this is set to 1 (vel mode)
[16:08:49] <andypugh> Does the encoder counter go to zero on index?
[16:09:47] <berny83> the only pin i've connected from the encoder is the index pin
[16:09:48] <andypugh> How are you counting encoder pulses?
[16:09:57] <berny83> I do not count them
[16:09:59] <andypugh> That won't work.
[16:10:55] <berny83> but using servo as step/dir does not means use "perfect" open loop stepper?
[16:11:17] <andypugh> Actually, I should say "I don't think that will work". My impression is that index homing relies on the encoder counts going to zero when the index is seen.
[16:11:47] <berny83> mmmm
[16:11:53] <andypugh> Yes, you have a perfect open-loop stepper. You can't do index-homing with a stepper.
[16:12:54] <pcw_home> Its possible but the system must be set up like a velocity mode servo
[16:13:10] <berny83> why not? If i link rigth wires... it's a software not a human mind.. :p
[16:13:25] <andypugh> This is not to say that you can't use the index pulse to improve the accuracy of homing, but it is not as simple as an INI file entry.
[16:13:30] <pcw_home> with PID loops, and the stepgens run in velocity mode
[16:14:01] <pcw_home> more things happen on index that you are aware of...
[16:14:11] <andypugh> To run the step-servo as a velocity-mode servo then there also needs to be encoder counters in the LinuxCNC world.
[16:14:18] <berny83> I would take PID control in servo system (not in linuxcnc) and use only the index pulse to better homing
[16:14:38] <pcw_home> wont work
[16:15:11] <berny83> it's a shame because I was very close to a solution...
[16:15:21] <andypugh> pcw_home: Well, it could work. But would need cleverness in HAL to hold the home-sw pin high until the index pulse is seen.
[16:15:34] <pcw_home> its more than that
[16:15:35] <berny83> index pulse has been recognised
[16:15:41] <_DJ_> gn8
[16:16:32] <berny83> only a little step and everythings will work fine....
[16:16:35] <andypugh> pcw_home: Indeed, you can't use HOME_TO_INDEX (or whatever the INI fle entry is). You need to meddle with the home-switch inputs in HAL
[16:16:42] <pcw_home> might be possible if the search for index is really slow
[16:17:04] <pcw_home> (might be useable)
[16:17:11] <andypugh> Yes, the latch move has to be slow enough to absolutely guarantee always seeing the index pulse.
[16:17:45] <andypugh> berny83: Are you using software step generation?
[16:17:49] <berny83> but in velocity mode it is not the same??
[16:17:53] <pcw_home> The index pulse cannot be lost as it always clears index ena
[16:17:55] <pcw_home> what is lost is the encoder count at index
[16:18:37] <berny83> i use 5i23 mesa board with hostmot2 for step generation
[16:18:38] <andypugh> In velocity mode you are using pulse-rate as a motor velocity comand, and all the position feedback etc happens in HAL with that PID and the HAL encoder counter.
[16:18:48] <andypugh> Ah, well, in that case....
[16:19:21] <andypugh> What sevo drives are you using?
[16:19:29] <pcw_home> there is firmware support for index on stepgens but its not supported
[16:20:14] <berny83> Delta AC servo system ASDA-B2
[16:20:31] <pcw_home> if you do the position loop in linuxCNC you can check on your actual following error
[16:21:17] <andypugh> The drives will take analogue command (torque or velocity)>
[16:21:39] <berny83> yes but they take also step dir command
[16:22:19] <berny83> and i use them because i'm more confident with this kind of command
[16:22:31] <andypugh> If you have a Mesa card then you can see step-dir as merely a very silly sirt of velcoity command.
[16:23:18] <andypugh> You have two choices (and it seem that you are trying to run a system that is half-way between the two).
[16:23:50] <njh> Hello, I have just been trying out Touchy on my 'new' touch screen
[16:23:56] <berny83> and i've never use analog command (i don't know if i could use 5i23 for analog command)
[16:24:27] <andypugh> 1) Run the system as a stepper system. All motion control is in the drive. If you want to use the encoders as index, then that needs a very slow latch move and some HAL logic.
[16:24:28] <njh> which is 1024x768 but the Touchy window is bigger than 1024x768 - can idea how to make it fit on the screen?
[16:25:07] <berny83> sure, my half-way will carry me in troubles.. i know
[16:25:20] <pcw_home> Yes the homing logic in motion assumes a servo system with encoder feedback to LinuxCNC
[16:25:38] <t12> pcw: i scoped out the communications from that mitsubishi encoder
[16:25:49] <pcw_home> This may be the best solution (and keep your drives honest)
[16:25:51] <andypugh> 2) Run the system as a PID servo system, with either velocity mode stepgens or analogue commands. This requires PID counters in LinuxCNC and encoder counters. You have a Mesa card, so at least we can be cnfident that you can accurately count the encoder pulses.
[16:25:52] <t12> it appears to be somehow both half and full duplex rs485
[16:26:19] <pcw_home> has RX and TX pairs?
[16:26:22] <t12> yeah
[16:26:30] <t12> it appears to do half duplex on one pair
[16:26:35] <t12> and the motor tx ALSO goes on the other pair
[16:26:40] <pcw_home> Ahh
[16:26:47] <t12> https://www.dropbox.com/sc/5skqj6nm3oc7c3m/vyunJ2h_oD
[16:26:50] <t12> +-5V
[16:26:55] <andypugh> njh: I think that it is the text-height setting in the config screen, but it has been a while
[16:27:06] <t12> i can see the binary counting for encoder position so i'm assuming its not grey/manchester/whatever encoded
[16:27:20] <andypugh> njh: Playing with the DPI setting in Linux generally might help too.
[16:27:41] <t12> the half duplex line always seems to have that noise spike during what i think is the rx/tx switchover in half duplex
[16:28:02] <berny83> delta driver could give me pulse index also as open collector source...
[16:28:21] <berny83> i don't know if this is an advantage for me
[16:28:52] <t12> i ordered a rs485/usb thing which hopefully I can rig to sniff the bus convinently. The only unknown part is the likely checksum at the end of the transmission, but theres only so many checksum algs
[16:29:53] <njh> andypugh: will give it a go but it was the width that was the problem, not the height
[16:29:54] <pcw_home> Theres a CRC reverse enginnering program I used
[16:30:03] <t12> maybe thats actually +-3.3
[16:30:21] <andypugh> berny83: For the stepper-mode solution you can probably use http://www.linuxcnc.org/docs/html/man/man9/flipflop.9.html to mediate the home switch signal. Wire clock and set to the switch, and then reset to the index. It will go high and stay high on the home-switch, then go low on the index pulse.
[16:30:32] <t12> that would be useful!
[16:30:51] <t12> i figured i could also arrange for a mesa card to be a rs485 sniffer, but i'm guessing it would take a fair amount of effort
[16:31:04] <andypugh> njh: DPI setting may be the solution then
[16:31:08] <pcw_home> reveng_crc maybe
[16:31:20] <pcw_home> Whats the data rate?
[16:31:39] <andypugh> t12: We have a driver for the Mesa UART module.
[16:32:08] <berny83> guys this is too advanced for me!! I'm a little scared..
[16:32:45] <andypugh> berny83: In that case you will have to give up on using the index for homing.
[16:32:50] <pcw_home> looks a little like 2 mbits/sec or so
[16:33:14] <pcw_home> or set the hal file up like a normal velocity mode servo
[16:33:14] <berny83> I have to go step by step, first understanding the logic, then I will study the "tools" for write that logic
[16:33:24] <andypugh> berny83: It can be done, but you are trying to use Index on a stepper system, and that is advanced.
[16:34:18] <andypugh> Do the drives support any sort of homing behaviour?
[16:34:37] <berny83> good question
[16:34:38] <t12> trying to eyebal from those traces
[16:34:57] <andypugh> (Basically you are trying to run the system open-loop, so that means that homing has to be in the drive, not in LinuxCNC)
[16:35:21] <pcw_home> T12: need a litte expansion/cursors
[16:35:49] <berny83> i check it immediatly
[16:36:08] <t12> yeah
[16:36:14] <t12> am not at scope right now, will recapture this even
[16:36:22] <t12> eve
[16:37:01] <pcw_home> might be kind of like the Fanuc (async but weird number of bits)
[16:37:43] <pcw_home> if you can see a binary count, then thers no embedded clock info so it may well be async
[16:37:51] <berny83> delta drivers seems to be not able to perform homing procedure
[16:38:31] <t12> i know if i fiddle with the shaft i see what i assume to be just the lsb's and crc changing
[16:38:52] <t12> large turns then affect the msb side
[16:56:01] <pcw_home> can you figure out what triggers the data transfer?
[17:02:34] <pcw_home> reveng.sourceforge.net is the crc tool
[17:19:19] <t12> i think its an approx 1byte xmit from the controller
[17:19:49] <t12> https://www.dropbox.com/sc/5skqj6nm3oc7c3m/vyunJ2h_oD#lh:0-2013-10-12%2023.12.38.jpg is the motor sending position
[17:20:04] <t12> https://www.dropbox.com/sc/5skqj6nm3oc7c3m/vyunJ2h_oD#lh:1-2013-10-12%2023.21.32.jpg is the control sending request, and the motor sending position on the same line
[17:20:28] <t12> the big spike in trace 2 is about where the controller tx ends and the motor tx begins
[17:24:24] <t12> thnx for the crc tool
[17:24:27] <t12> that is max useful in general
[17:24:31] <pcw_home> what is m2?
[17:24:57] <pcw_home> looks like TX and RX
[17:25:24] <t12> m2 is 1-2
[17:26:00] <t12> or 2-1, whatever order it was
[17:26:33] <pcw_home> OK
[17:26:34] <t12> so should be the de-differentiald data
[17:27:09] <pcw_home> yeah so what other signal is used?
[17:27:24] <t12> so theres MD MDR MR MRR
[17:27:34] <t12> the traces in the dropbox are each
[17:27:45] <t12> the responses from motor appear to be transmitted on BOTH
[17:27:51] <t12> btu the controller only sends requests on one
[17:27:58] <t12> i'm assuming this is some leftover backwards compatability stuff
[17:28:15] <pcw_home> yeah maybe so
[17:28:34] <t12> or maybe they have multiple controllers that talk to the motor and some want to do full duplex
[17:29:03] <t12> the rest of the pins are power related, battery, logic power, cable shield, logic ground
[17:29:21] <pcw_home> I have a 400W Yaskawa servo motor that has a single (I assume RS-485) pair for encoder connection
[17:29:24] <pcw_home> its may well be similar
[17:29:25] <t12> alot of transients show up on them
[17:29:50] <t12> i also found a random renishaw doc
[17:29:57] <t12> that implies that the melservo encoders are rs485
[17:30:03] <pcw_home> They will be a lot noisier whin the m otor running
[17:30:11] <t12> for some linear encoder product they sell that interfaces with them
[17:30:51] <t12> http://resources.renishaw.com/download.aspx?lang=en&data=23138
[17:31:05] <pcw_home> the transient is probably easily maskable as the start bit detection logic can be held off
[17:31:07] <t12> last page
[17:33:09] <t12> will there be issues getting mesa serial to deal with the maybe asynch nature of the protocol?
[17:34:39] <pcw_home> Looks like theres just a 1/2 and full duplex option
[17:35:41] <pcw_home> its probably most easlily done as a varient of the Fanuc (looks like a clone)
[17:39:17] <WalterN> herm
[17:39:43] <WalterN> looking for a BT40 Coolant Inducer tool holder
[17:40:04] <WalterN> kinda hard to find... I see a bunch of CAT Coolant Inducers..
[17:40:17] <uw> make one
[17:40:27] <uw> with cnc abilities
[17:42:03] <WalterN> and magical unicorn horn
[17:44:09] <uw> *~you gotta believe~*~
[17:45:30] <WalterN> http://www.youtube.com/watch?v=9auOCbH5Ns4
[17:45:52] <WalterN> lol
[17:57:09] <uw> lol that weebl guy must have made 1000 videos
[17:59:12] <njh> andypugh: changing fonts from 90 dpi to 72 dpi fixed it, thanks!
[18:00:17] <andypugh> WalterN: BT and CAT are the exact same taper.
[18:00:26] <andypugh> Not sure that helps.
[18:00:38] <WalterN> they will fit in the holders too evidently
[18:01:19] <WalterN> just not in the carousel
[18:02:00] <andypugh> My machine was built as 30INT, but I added a pneumatic drawbar for BT30, so then it was BT30. Then I got a whole load of SK30 holders cheap, so I shortened one drive dog and now I have a hybrid that takes SK30 holders with BT30 pull-studs :-)
[18:03:10] <WalterN> :3
[18:16:34] <pcw_home> t12 do you have a encoder PN? maybe I can snag on on Ebay
[18:16:44] <pcw_home> one on
[18:21:44] <t12> I'll check when I get home, I think they're sold coupled to the motors only
[18:22:35] <t12> the wee little motors on ebay seem to be in the 75-100 range shipped
[18:23:27] <t12> http://www.ebay.com/itm/MITSUBISHI-HC-KFS053-MELSERVO-AC-Servo-Motor-50W-3000r-min-a25-/160906864246?pt=LH_DefaultDomain_0&hash=item2576cbe676
[18:23:38] <t12> i _think_ that whole series uses the same encoder but not sure
[18:39:18] <WalterN> what does this do? http://www.ebay.com/itm/Transformer-34-KVA-SQUARE-D-460V-pri-230V-sec-3-ph-34T143HDIT-5366-/280909595442?pt=BI_Circuit_Breakers_Transformers&hash=item4167844332
[18:41:24] <toastyde1th> it's a three phase, 460v to 230v transformer
[18:41:52] <WalterN> so 460 from the power company comes in, and 230 goes out
[18:41:57] <WalterN> can it be the other way around?
[18:42:51] <toastyde1th> yes
[19:09:41] <awyea> anybody have any experience with BBB and linuxcnc? i want to run the stepconf wizard
[19:15:33] <andypugh> awyea: It can be done, but I don't think any of the people who have done it are here.
[19:16:10] <andypugh> You will probably find the mailing list more help.
[19:16:37] <andypugh> (And I am not sure that stepconf knows about the BBB, it assumes a parallel port)
[19:18:19] <andypugh> Goodnight chaps
[19:18:31] <awyea> k i'll try the mailing list, thanks
[20:38:38] <MacGalempsy> evening gents
[20:42:35] <MacGalempsy> time to unbox this new linux box and get a latency test started
[21:08:10] <CaptHindsight> MacGalempsy: what cpu and chipset?
[22:42:49] <MacGalempsy_> CaptHindsight: http://www.ebay.com/itm/310754480663?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649
[22:43:41] <MacGalempsy_> this is my first linux box, so at the moment, I am trying to figure out which version of ubuntu I am running, then download and run the latency test
[23:10:04] <MacGalempsy_> guys I got this box that has ubuntu 13, but the manual said 8 or 10 would work with linuxcnc. any help with which one is best?
[23:22:37] <jp_mill> 10 should be fine for what you need
[23:32:40] <xxoxx> hi
[23:32:51] <xxoxx> can you mill with EDM ?
[23:32:55] <MacGalempsy_> ok great, its downloading right now
[23:33:05] <MacGalempsy_> edm is for cutting
[23:33:12] <xxoxx> right
[23:33:17] <MacGalempsy_> xxoxx: there is wire and sinker
[23:33:27] <xxoxx> i wonder what would happen if you cross feed on a sinker
[23:33:29] <MacGalempsy_> wire will cut
[23:34:09] <MacGalempsy_> so with the sinker, you cut the electrode, then essentially shock away the metal within a fluid bath
[23:34:23] <xxoxx> right. I have a sinker, but it only goes up and down
[23:34:33] <xxoxx> kind of like a jig bore
[23:34:56] <MacGalempsy_> i think the process is too slow for "milling"
[23:35:25] <MacGalempsy_> that being said, I only seen youtube videos on it
[23:36:05] <xxoxx> right
[23:36:38] <xxoxx> i was consider cases for micro-machining, where tiny bits would be too weak
[23:37:26] <xxoxx> But I can't think of ways to accurately know the Z position of the tip
[23:50:25] <toastyde1th> xxoxx, you can feed in any direction you have a nervous control in
[23:50:59] <toastyde1th> there is edm turning, milling, grinding, etc
[23:51:09] <toastyde1th> edm grinding is fucking bizarre but whatever
[23:51:22] <toastyde1th> they tend to be custom built, custom controlled machines
[23:52:16] <xxoxx> would like to custom build a desktop edm mill
[23:52:27] <xxoxx> for fine hobby grade work
[23:52:38] <toastyde1th> the feed rate is controlled by the current to the electrode, not by any other factor
[23:52:44] <toastyde1th> there is no following error
[23:52:58] <toastyde1th> well, there is, but nobody cares about it or tracks it
[23:54:35] <toastyde1th> the neat thing about edm milling/grinding is that since the tool revolves, you can redress the electrode
[23:54:58] <xxoxx> redress electrode?
[23:55:11] <toastyde1th> so you have a spinning carbon or copper cylinder
[23:55:23] <toastyde1th> and somewhere in the workspace you have a diamond tool
[23:55:48] <toastyde1th> and when you finish your roughing pass, you just take the electrode over to the cutting tool and shave some off
[23:56:05] <toastyde1th> you now know your tool diameter to the limits of your ability to measure
[23:56:12] <toastyde1th> just like on a grinder
[23:56:46] <xxoxx> neat...
[23:56:49] <xxoxx> i see
[23:56:50] <toastyde1th> also, if you're really going to do this, look up jig grinders.
[23:57:04] <xxoxx> you could do this per pass, constantly updating tool info
[23:57:06] <toastyde1th> they have an additional spindle axis, and if you're going to go balls to the wall and create a machine THIS custom
[23:57:16] <xxoxx> ok
[23:57:18] <toastyde1th> you might as well include all the neat accuracy features of a jig grinder
[23:57:36] <MacGalempsy_> so does the linuxCNC package install the operating system, too
[23:57:37] <MacGalempsy_> ?
[23:57:37] <xxoxx> yeah. would be very useful
[23:58:00] <xxoxx> MacGalempsy_, yeah. linux and all
[23:58:25] <xxoxx> ok jig grinder.... food for thought...
[23:58:57] <toastyde1th> if you want to put a hole in something
[23:59:08] <toastyde1th> a jig grinder is pretty much the best way to do it
[23:59:14] <toastyde1th> from an accuracy standpoint