#linuxcnc | Logs for 2017-01-10

Back
[00:00:19] <ve7it> Machine seems new to me, but it was born last century in 1997. After 20 years, I guess I should not be surprised that cheap Chinese caps have gone bad.
[00:02:48] <Gene_home> any suggestions on a spindle motor with 25,000 - 90,000 RPM small collet?
[00:03:49] <Jymmm> ve7it: well a cap is better than the whole motor at least
[00:03:54] <SpeedEvil> 90000 - good luck
[00:04:03] <SpeedEvil> what wattage are you hoping for
[00:04:03] <ve7it> trim router might get you to 30,000
[00:04:16] <SpeedEvil> 90000 I'm unsure can be done without air bearings
[00:04:34] <SpeedEvil> Though RC stuff does abuse ball bearings up to maybe 50K
[00:04:57] <Jymmm> Gene_home: http://surgicalpower.com/products/hall-5058-01-surgairtome-ii-high-speed-surgical-drill-90k-rpm/
[00:05:14] <Gene_home> wow...
[00:06:12] <Gene_home> do you have a recommended trim router?
[00:07:11] <ve7it> turbine dental handsets are not that expensive and run 250,000 rpm or so and your dentist can be a good source of carbide dental burrs
[00:09:31] <ve7it> I have a Porter cable trim router. Base is easily removed... only disadvantage is that it is 1/4" collet http://www.portercable.com/products/ProductDetail.aspx?ProductID=11106
[00:10:41] <ve7it> they are in the $100 category
[00:11:05] <Gene_home> is anyone using the dentist drill effectively?
[00:11:26] <SpeedEvil> for what
[00:11:54] <SpeedEvil> AIUI, they have terrible general accuracy - they're OK at spinning with reasonable power at very high speeds
[00:11:56] <Gene_home> i friend uses a .020 drill bit on wood for inlays and is using a 30k rpm spindle... wishes he could go up to 90k
[00:12:14] <ve7it> dont know of anyone.... I have collected a few burrs from the dentist.... they tend to throw them away after 1 use instead of trying to sterilize them
[00:12:31] <SpeedEvil> Plus, tooth is quite abrasive
[00:12:37] <SpeedEvil> and blunt means heat, which is bad
[00:13:39] <Gene_home> what is the shank diameter of the dentist bit?
[00:16:16] <ve7it> let me check...
[00:19:00] <ve7it> looks like 0.090 +-
[00:20:04] <Gene_home> interesting
[00:20:43] <Gene_home> ve7it - can you share a picture of your setup?
[00:21:42] <ve7it> entire bit is about 0.865" long... cutting portion is 0.050" ball end
[00:22:05] <ve7it> I havent used these bits yet... do you want a picture of the bit?
[00:22:32] <Gene_home> your mounted portercable on your machine
[00:23:43] <ve7it> ahh.... its not actually mounted.... i got it for a future router project.... my running machine is a lathe mill combo called a shoptask
[00:30:20] <Gene_home> what is one of those worth used?
[00:32:45] <ve7it> no idea... mine has the factory cnc addon and I have upgraded it with a lathe spindle encoder... new was about $5k, kind of pricey for moderate performance
[00:33:18] <ve7it> but it hard to get used machines here north of the border
[00:34:14] <ve7it> http://members.shaw.ca/swstuff/spindle-encoder.html has some pix of the spindle encoder I did
[00:37:32] <Gene_home> interesting
[00:51:14] <Gene_home> afk
[00:57:50] <ve7it> https://imagebin.ca/v/38NEbgtoNHF8 the shop task when it was very new....
[01:34:15] * archivist giggles at Wolf_ , you know a aaaaarguino is cheaper :)
[02:29:58] <Deejay> moin
[05:13:50] <XXCoder> unerlord
[05:13:56] <XXCoder> *underlord
[05:41:24] <jthornton-> morning
[05:43:51] <XXCoder> yo
[05:46:38] <jthornton> looks like rain for the next week here
[05:46:59] <XXCoder> its on and of here. either low-ish 30s and rainy or 20s f'
[05:47:44] <jthornton> 50f this morning and really windy
[05:57:49] <jthornton> I gotta figure out how to make a 2x3 5 1/2" wide in 3 places to fasten them to the purlins
[06:15:15] <jthornton> log
[06:15:15] <c-log> jthornton: Today's Log http://tom-itx.no-ip.biz:82/~tom-itx/irc/logs/%23linuxcnc/2017-01-10.html
[07:52:30] <Wolf_> archivist: yah, they are cheaper, but mi5 box for $70 isn’t terrible either, from same seller the mp1s came from
[07:53:38] <archivist> I am in the middle of modding the code a bit, faster and deals a bit better with a buggy high resistance probe
[07:54:27] <Wolf_> anyways, I was leaving feedback on ebay for the probe and checked to see what else they had listed
[07:54:56] <archivist> the force from various directions varies a huge amount on the valeron probe
[07:56:04] <Wolf_> next cheapest mi5 on ebay is $150...
[07:56:44] <archivist> never buy a http://www.ebay.co.uk/itm/Cat-50-CNC-TOUCH-PROBE-Valeron-Digital-Technologies-/111177222017
[07:57:14] <Wolf_> lol, noted
[07:57:43] <archivist> the contacts are nothing like a renishaw, they must have tried to get around the patent, the wrong way
[07:57:55] <Wolf_> specs for mp1 say 57g, giving at 115g
[07:58:10] <Wolf_> max
[07:58:48] <archivist> I can sense at about 20g one way, or 90gr another, or 400 end on
[07:59:52] <Wolf_> yeah that varies some doesn’t it lol mp1 says 380g on Z is spec
[08:01:01] <archivist> I had set a threshold of 150 to arm, but the valeron never drops below 200+ so I have to mod the code
[08:02:35] <Wolf_> weird, does make you wonder how the contacts are set up in it...
[08:03:07] <archivist> I took it apart some time ago
[08:04:37] <archivist> http://www.collection.archivist.info/searchv13.php?searchstr=valeron
[08:05:11] <Wolf_> lets see, amazon, hx711 $9….
[08:05:41] <archivist> £1.5 from hong kong
[08:06:06] <Wolf_> yeah, but week-month lead time then
[08:06:44] <Wolf_> I expect to pay more if its gonna be here in 2 days lol
[08:07:47] <archivist> even if not used for probe conditioning the setup is good for probe testing
[08:08:27] <Wolf_> yeah, thats what I was thinking when I saw the trigger forces on the spec sheet last night
[08:09:29] <Wolf_> could also use a load sensor + spring and plate for auto tool offset I bet
[08:10:23] <archivist> what does annoy me is the PH6 I have has a faulty LED, I wanted to light it up then the arguiono armed itself
[08:11:24] <Wolf_> lol thats more like it, hx711 10 pack, $12 same day available from amazon lol
[08:12:01] <archivist> some the stuff it damned cheap
[08:13:55] <Wolf_> how is the resolution on the load cell bars? 1kg ok or should I look for a 100 and 500g
[08:13:56] <archivist> we just need a pcb to hold a few optos some screw terminals and sockets for hx711,buzzer, cal, switch and the arguino
[08:14:33] <archivist> 100 is a bit light got the valeron, 500 should be ok
[08:15:39] <archivist> I started playing with a 3kg then a 100kg then...probe and using the 100g
[11:30:24] <Loetmichel_> hmpf... just came home from work. Saw my backyard... 10cm snow... thought to myself : NOW would be the time to build a roboplow with salt thrower and street brush attachment... then i looked at my mancave: maaan, the CNC is way to small for that.. so is the lathe... and i need more rooooom... *sad puppy*
[11:30:58] <Wolf_> modular bolt together
[11:34:39] <Loetmichel_> Wolf_: goto youtube, throw in "roboplow"... its just too big for my 200mm*110mm*110mm travel mill and my C0 lathe :-(
[11:35:14] <Wolf_> all in setup :P
[11:37:00] <Wolf_> and I don’t really think it need as much machine work as they did
[11:41:09] <gregcnc> http://mashable.com/2017/01/10/china-manufactures-ballpoint-pen/
[11:46:53] <archivist> just read the bbc version of that chines ball news, does say something about all the ball bearings coming from there
[11:52:18] <Loetmichel_> fun thing is i already have most of the parts here. should have been a "mobile battery pack" for quadcopter recharging on the model airfield (parking lot is a good walk from the airfield)... but never came around to finish it and attach a plow and / or a street brush.
[11:52:35] <Loetmichel_> http://www.cyrom.org/palbum/main.php?g2_itemId=5531
[11:52:45] <Loetmichel_> http://www.cyrom.org/palbum/main.php?g2_itemId=5534
[11:52:58] <Loetmichel_> http://www.cyrom.org/palbum/main.php?g2_itemId=5516
[11:53:10] <Loetmichel_> http://www.cyrom.org/palbum/main.php?g2_view=core.DownloadItem&g2_itemId=6587
[11:53:55] <Wolf_> I have 2x jazzy power wheel chair/mobility scooters that at some point I want to convert to RC bot platforms
[11:54:20] <Loetmichel_> ... just never found the time to finish it. and now the 7 12V7A lead acid blocks i bought to put in there are dead because of sulfide buildup :-(
[11:54:48] <Wolf_> yeah, that sucks, and only 7ah?
[11:54:57] <Loetmichel_> 7 times 7ah
[11:55:05] <MacGalempsy> that looks like a fun project
[11:55:09] <Loetmichel_> was just more convenient to stack inside there ;)
[11:55:22] <Wolf_> I forget whats in teh power chairs
[11:55:27] <Loetmichel_> than one big block
[11:55:32] <gregcnc> grass snow robot http://thekobi.com/meet-kobi/
[11:55:50] <Loetmichel_> the big ones: usually 2 gel batteires with 24Ah or bigger each
[11:56:02] <Loetmichel_> i had a girlfriend once that sat in one of these
[11:56:29] <Wolf_> go bigger mower.. https://www.youtube.com/watch?v=vzffTzZITLc :P
[11:57:12] <Loetmichel_> gregcnc: waaay to fancy and to much plastics ;)
[11:57:30] <Wolf_> iirc I think its 35ah x2 in these chairs
[11:58:01] <Loetmichel_> as i said: "or bigger"
[11:58:24] <Loetmichel_> the one my girlfriend had was already 310 lbs tho
[11:58:40] <Loetmichel_> a bit "unwieldy" to put in the cars trunk ;)
[11:58:50] <Wolf_> yup lol, I have a backup pump in my house that has 12V75AH x2
[12:00:10] <Loetmichel_> but that would be way to much for a roboplow. my first design for it was this size: http://www.cyrom.org/palbum/main.php?g2_view=core.DownloadItem&g2_itemId=5338
[12:00:55] <MacGalempsy> got some caps and a resistor in the mail today, so now the holder is being printed!
[12:01:05] <Loetmichel_> ... and could take 9 12V 7Ah batteries in the chassis and 2 in the "cockpit"
[12:01:20] <MacGalempsy> cant wait to get them installed and try to re PID tune the setup
[12:01:22] <Wolf_> cool
[12:01:30] <Loetmichel_> downsized it then to 7 batteries and only two axles
[12:01:41] <Wolf_> my rc truck is almost that big lol
[12:01:47] <Loetmichel_> to fit better with my cars trunk.
[12:03:58] <Wolf_> http://i.imgur.com/2mA3GXJ.jpg
[12:05:15] <Loetmichel_> that would be much to light to do as a snow plow tho
[12:05:23] <Loetmichel_> also way to small wheels
[12:05:25] <Wolf_> it is
[12:05:32] <Wolf_> wheels are 8"
[12:05:37] <Wolf_> almost 9"
[12:06:18] <Loetmichel_> yeah, wheels on mine are from a sack barrow, 250mm diameter, so about 10"
[12:06:43] <Wolf_> http://i.imgur.com/y9af9Ib.jpg 250mm quad under the truck
[12:07:03] <Loetmichel_> nice
[12:07:20] <Loetmichel_> i have a 1:8 size glo engine truck
[12:07:25] <Loetmichel_> nice toy
[12:07:35] <Loetmichel_> about the size of the one in the front
[12:08:38] <Wolf_> front is a 1/16 traxxis mini revo
[12:11:14] <Wolf_> all of my rc stuff is shelved for a while tho =/
[12:11:29] <Wolf_> too much other things that need to get done firs
[12:11:36] <Wolf_> first
[12:23:15] <IchGucksLive> hi lots of snow today
[12:25:01] <DaPeace1> you seem to be the daily weather forecast :-D
[12:26:34] <IchGucksLive> as work is interupted by
[12:28:04] <IchGucksLive> someone shoudt get the need of a servo tread in wheezy to the debounce manuel
[12:28:16] <IchGucksLive> in 10.04 it workes without
[12:29:03] <IchGucksLive> but in the new wheezy i got it not to work till i added a addf servo-tread
[12:29:14] <IchGucksLive> http://linuxcnc.org/docs/2.7/html/hal/rtcomps.html#_debounce
[12:29:19] <IchGucksLive> there is nothing on it
[12:29:30] <terry> Hi everyone
[12:29:37] <IchGucksLive> ;-)
[12:30:03] <terry> Is there a way to have the Z axis move first when M6 is called?
[12:30:17] <IchGucksLive> G30
[12:30:36] <IchGucksLive> tool change position
[12:31:03] <terry> Call G30, then call Tn M6 G43?
[12:32:00] <Tom_itx> it's in your home position order in the ini
[12:32:11] <Tom_itx> forget what it's called off hand
[12:32:19] <IchGucksLive> http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G30-G30_1
[12:33:05] <IchGucksLive> terry: you can edit your post on tool change
[12:33:19] <IchGucksLive> give it a z move bevor change
[12:33:20] <Tom_itx> HOME_SEQUENCE = 1
[12:33:28] <Tom_itx> look that up in the help
[12:33:35] <Tom_itx> it's in the axis section of the ini
[12:33:44] <terry> Homing does move Z first.
[12:33:51] <Tom_itx> it sets the order of how the axis move
[12:34:21] <Tom_itx> my z is 0, my x y are 1
[12:34:33] <Tom_itx> z always moves first
[12:34:38] <JT-Shopp> he is talking about tool change not homing
[12:35:03] <Tom_itx> i thought that was any tool retract movement
[12:35:23] <JT-Shopp> nope
[12:35:40] <Tom_itx> nevermind...
[12:36:08] <IchGucksLive> Tom_itx: while you are on where is the new log
[12:36:16] <Tom_itx> zlog
[12:36:17] <Tom_itx> or
[12:36:19] <Tom_itx> log
[12:36:20] <c-log> Tom_itx: Today's Log http://tom-itx.no-ip.biz:82/~tom-itx/irc/logs/%23linuxcnc/2017-01-10.html
[12:36:23] <JT-Shop> TOOL_CHANGE_QUILL_UP = 1
[12:36:28] <terry> Just check the ini file, X and Y are 1, Z is 0.
[12:36:32] <JT-Shop> [EMCIO]
[12:36:44] <JT-Shop> http://linuxcnc.org/docs/2.7/html/config/ini-config.html#_emcio_section
[12:36:48] <Tom_itx> IchGucksLive the 2nd one is temporary
[12:36:51] <JT-Shop> terry: ^^
[12:36:53] <Tom_itx> a test server
[12:37:23] <Tom_itx> using fancy jt'ified code
[12:37:31] <JT-Shop> lol
[12:37:41] <terry> Thanks JT-Shop
[12:37:43] <Tom_itx> jt, check the channel for a note..
[12:38:32] <JT-Shop> ok
[12:38:45] <Tom_itx> it'll be even slower on the old server
[12:39:06] <IchGucksLive> JT-Shop this moves a G0 G53 Z0
[12:39:18] <IchGucksLive> to the reference z
[12:39:35] <JT-Shop> I know that
[12:40:09] <IchGucksLive> on Rotary the point might be a rotation point not the wanted Z max
[12:40:25] <IchGucksLive> as mine is A middel
[12:40:41] <IchGucksLive> so the graphics show all rotation perfect
[12:40:56] <IchGucksLive> for the sculpting
[12:41:17] <IchGucksLive> if i intiat on that mashine it will break almost everything
[12:41:41] <IchGucksLive> G30 is best to use
[12:42:14] <IchGucksLive> or even better to initiate in the generating post bevor Tx M6
[12:44:59] <IchGucksLive> G1 G53 Zsave Fspeed
[12:45:01] <IchGucksLive> Tx M6 G43
[12:45:02] <IchGucksLive> G coordinate system
[12:45:13] <IchGucksLive> i woudt use this
[12:47:10] <terry> JT-Shop, close, but it seem to ignore TOOL_CHANGE_POSITION = 0.098 6.4 14.785
[12:47:22] <terry> It goes to Z0 instead
[12:47:44] <IchGucksLive> thats what i said
[12:47:57] <JT-Shop> yea, you can use either one but not both
[12:48:13] <terry> Empty spindle noes on the empty table is Z0 on my machine.
[12:48:18] <IchGucksLive> TOOL_CHANGE_QUILL_UP = 1 - The Z axis will be moved to machine zero prior to the tool change when the value is 1. This is the same as issuing a G0 G53 Z0
[12:48:38] <JT-Shop> yes it is but automagic
[12:48:51] <terry> Yes I read that in the docs just now
[12:50:26] <terry> I prefer my tool offsets to be the actual length the tool hangs below the spindle nose.
[12:50:51] <terry> That allows for quick at-a-glance sanity check of tool offsets.
[12:51:22] <IchGucksLive> Terry move to G1 X0.098 Y6.4 Z14.785
[12:51:27] <IchGucksLive> in MDI
[12:51:33] <IchGucksLive> give it a G30.1
[12:51:47] <IchGucksLive> move somwhere else
[12:51:57] <terry> Yes, I have G30 set up, use it at end of programs.
[12:51:58] <IchGucksLive> give it a G30
[12:52:27] <IchGucksLive> so where is the problem only Z first on that point
[12:53:01] <terry> I can add an extra line before a tool change, but just thought there would be a better way.
[12:53:07] <terry> Thanks everyone.
[12:53:34] <IchGucksLive> be aware
[12:53:57] <IchGucksLive> changeing to G53 needs to be rechanged to G54
[12:54:19] <JT-Shop> you can't change to G53
[12:54:38] <IchGucksLive> YOU can also use G28 the same but not on M6 auto effect
[12:57:25] <JT-Shop> some idiot at mcmaster thinks adding scenes to solidworks parts is cool
[12:57:54] <miss0r> but it IS cool :]
[12:58:57] <IchGucksLive> what is scenes
[12:59:13] <IchGucksLive> seams
[13:00:42] <JT-Shop> took 15 minutes of my time to remember how to turn that crap off
[13:01:18] <IchGucksLive> ok igot it
[13:01:35] <miss0r> I did a 70,000mm round bar. I hit the numbers perfectly within what I can measure here. but stupid me forgot to take temperature into acount. it shrunk 0.003mm. either way; I made a very short clip of my lathe grinder attachment in action, should anyone be interrested: https://drive.google.com/open?id=0B51cA8Udo5i7d2R3dEdCd1pWbWs
[13:01:38] <IchGucksLive> like blender does
[13:02:39] <miss0r> also, that video is of the roughing with the grinder :)
[13:02:53] <miss0r> it was re-dressed before sneaking up on my tolerence
[13:05:16] <IchGucksLive> im off Gn8 need to shuffle one more time this day
[13:13:00] <JT-Shop> terry: did you sort out your problem?
[13:25:23] <gregcnc> everyday I'm shuffling https://www.youtube.com/watch?v=QXW1u_1ksJA
[13:26:56] <gregcnc> jt-shop I downloaded ball bearing model somewhere once, came in as an assembly with balls cage shield as parts
[13:28:11] <Wolf_> bunch of mcmaster parts are like that
[13:33:14] <terry> JT-Shop: No, but it is not a big deal, just would have been nice.
[13:35:34] <Roguish> if you don't actually need the bearing internals, they are nothing but a waste of time and computer resources. better to use a simplification. same with screw threads, which mcmaster likes to do also.
[13:35:38] <terry> The name TOOL_CHANGE_QUILL_UP is not very good, as it implies that the quill will move UP, but that is paradigm dependent, in my case it goes DOWN!
[13:36:23] <Wolf_> machine setup…
[13:36:41] <terry> A better name might be TOOL_CHANGE_QUILL_Z0
[13:36:47] <JT-Shop> terry: do you home the Z up to the top?
[13:36:49] <Wolf_> typical is home/zero up at max height over Z
[13:36:57] <terry> Yes
[13:37:09] <JT-Shop> and that is Z0
[13:37:15] <terry> No
[13:37:23] <Wolf_> then everything is negative numbers going towards table
[13:37:25] <JT-Shop> that is the problem
[13:37:37] <terry> Yes
[13:37:45] <Wolf_> touch off gets DRO showing Z zero off teh work
[13:37:47] <JT-Shop> normally Z0 is all the way up
[13:38:00] <terry> That gives tool lengths that are actual tool lengths.
[13:38:24] <Wolf_> no, thats how you wreck your quill
[13:38:30] <Wolf_> spindle/vice
[13:38:58] <terry> Yes, G54 has work surface as Z0.
[13:39:06] <Roguish> time for some Dick Dale and 15 miles on the indoor trainer.......raining like crazy outside.
[13:39:21] <Wolf_> yup, so why have machine Z 0 on the table…
[13:40:11] <terry> Well, then the distance on the DRO is actually the distance from the tool to the table.
[13:40:17] <terry> or the work..
[13:41:09] <terry> Why would one put Z0 at the top of the axis?
[13:41:21] <Wolf_> so you don’t crash the machine
[13:41:47] <terry> Why would one crash the machine?
[13:41:49] <cradek> it's what every operator expects, and probably also almost every gcode program
[13:41:57] <Wolf_> ^
[13:42:02] <cradek> why would you make positive X to the right? same reasons
[13:42:18] <Wolf_> pretty much standard machine setup for mills
[13:42:32] <terry> OK, I'll think about it.
[13:42:44] <roycroft> there is no think
[13:42:47] <roycroft> there is just do or not do
[13:42:57] <cradek> heh
[13:43:00] <Wolf_> lol
[13:43:53] <terry> How does that effect tool lenghts tough?
[13:43:56] <Wolf_> on a cnc mill you need to do a touch off no matter what before starting so machine Z0 is more relative to back end stuff anyways
[13:44:18] <cradek> it doesn't have anything to do with tool lengths
[13:44:52] <terry> I seen a machine once where the tool lengths were the distance, at quill up, of the tool tip to the work. That was wierd.
[13:45:52] <cradek> in linuxcnc they can be positive or negative and referenced to anything you want
[13:46:58] <terry> OK, will change it around and see how it works. Thanks everyone.
[13:47:40] <Wolf_> yeah, the home Z0 being up isn’t going to change anything you will notice, except for all the internal things working correctly like tool change
[13:48:20] <Wolf_> DRO will show relative to tool length after you touch off work
[14:36:24] <terry> OK, did it, as Wolf_ said, changed nothing to me.
[14:36:49] <terry> Thanks again.
[14:39:59] <pfred1> I am writing a G Code file by hand and I am trying to understand how I figure out the coordinates for a Z axis move?
[14:40:27] <pfred1> I got X and Y down OK but I'm stuck with figuring out the depth
[14:40:47] <pfred1> there's just somethng here that isn't clicking for me
[14:41:29] <pfred1> I know when I run a file made by a CAM program I just touch off Z and the machine cuts from there
[14:41:55] <pfred1> but how does the CAM program ah figure out the top of the work?
[14:42:10] <jdh_> you tell it material thickness
[14:42:20] <pfred1> you do?
[14:42:29] <pfred1> I never have so far
[14:42:32] <jdh_> I do.
[14:42:41] <pfred1> really?
[14:42:48] <jdh_> guess that is mainly for cut through though
[14:42:50] <pfred1> all this time I never have
[14:42:59] <pfred1> yeah this is just engraving
[14:43:06] <jdh_> I use 0 for top of work
[14:43:07] <pfred1> but to a depth
[14:43:14] <pfred1> ah ha
[14:43:31] <pfred1> but machine zero is way above the table and the material thickness might vary
[14:43:55] <jdh_> 0 is wherever I touch off to
[14:44:04] <pfred1> well there's no might abotu it the material is going to be an arbitrary value
[14:44:08] <jdh_> which is usually top of work
[14:44:18] <pfred1> OK that's relative zero?
[14:44:22] <sync_> yes
[14:44:26] <sync_> G54 all the way
[14:44:27] <pfred1> ah ha
[14:44:28] <jdh_> g54
[14:44:36] <pfred1> OK so I have to declare G54
[14:45:00] <pfred1> yeah that's where I thought I was screwing up
[14:45:02] <jdh_> it is good praxtice to do so
[14:45:06] <pfred1> I was using G90
[14:45:39] <pfred1> so no G90 use G54
[14:46:04] <pfred1> but I usually only ever touch off the Z
[14:46:25] <pfred1> with this job where it cuts is pretty critical
[14:46:46] <pfred1> in the X, and Y Z somewhat
[14:47:46] <pfred1> nor one program I ever ran has G54 in it
[14:47:54] <pfred1> pfred1@buck:/home/giga/G-Code/MyTries$ grep G54 *.ngc
[14:48:13] <pfred1> how the hell do these pther programs work?
[14:49:08] <pfred1> is G54 like the default state?
[14:49:12] <jdh_> yes
[14:49:22] <pfred1> ah ha!
[14:49:40] <pfred1> see I don't know this stuff
[14:49:56] <jdh_> if you touch off and don't specify. it sets g54
[14:50:16] <jdh_> check the mdi tab that shows current actice
[14:50:32] <jdh_> active
[14:50:32] <pfred1> here's something I always wondered is there a way to get LinuxCNC to spit out what modes are active?
[14:50:45] <pfred1> oh really?
[14:51:04] <pfred1> I'm going to have ot look at that tab more carefully
[14:51:28] <pfred1> I just go there and G0 X0 Y0 Z0
[14:51:36] <pfred1> to home out
[14:51:54] <Wolf_> can tell who doesn’t drive their machine by hand code :p
[14:52:14] <pfred1> Wolf_ yeah i use CAM software
[14:52:17] <MrSunshine> hmm so .. machine straight to within about 0.4mm .. but something is changing all the time and i cant figure out what .. ive put it on 3 feet .. to not introduce any twist in it .. get two sides perfectly level .. then check .. and after a while i check again the other .. and its off again .. like wtf
[14:52:23] <pfred1> point click and shoot all the way
[14:52:39] <Wolf_> hand g-code = manual machining for me right now lol
[14:52:50] <MrSunshine> not the best straight edge atm tho but cant figure out why its not reproducable
[14:52:53] <pfred1> but I a making this file to test the spindle out
[14:53:01] <pfred1> I think the PSU is a POS
[14:53:22] <pfred1> I think it can't really supply any current at load
[14:53:30] <Wolf_> sorta waste of time to model, cam and load g-code just to face off a part or drill some holes
[14:53:37] <pfred1> so I want the machine to make long passes so I can check the current
[14:54:00] <pfred1> at various depths and feed speeds too
[14:54:14] <pfred1> I basically want to see what I can get away with
[14:54:40] <Wolf_> use one of the PY scripts to make some gcode, then save/edit it with text editor
[14:54:46] <pfred1> so here I am writing that test file by hand
[14:54:47] <jdh_> it is good practice to specify all needed modes, g54 included
[14:54:49] <Wolf_> like the facing one
[14:55:18] <pfred1> yeah but facing just goes back and forth at the same depth and speed
[14:55:31] <Wolf_> hand edit it
[14:55:31] <JT-Shop> http://gnipsel.com/linuxcnc/g-code/index.html
[14:56:12] <Wolf_> faster then writing the whole code by hand
[14:57:14] <pfred1> OK so if i touch off I'm in G54 but let's say in the beginning of a program I have a G90 then what happens?
[14:57:54] <JT-Shop> http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g90-g91
[14:58:17] <pfred1> JT-Shop that tells me what it does but it doesn't tell me what happens
[14:58:39] <pfred1> because I've been there
[14:59:12] <pfred1> if my pile of foam board wasn't buried under snow I'd go get a piece
[14:59:28] <Jymmm> wuss
[14:59:36] <pfred1> but I got a piece of MDF I'm ging to run this file on
[14:59:51] <Jymmm> pfred1: GO NAKED and GO GET THE FOAM!!!
[14:59:52] <pfred1> Jymmm it's liek a quarter of a mile away
[15:00:06] <pfred1> through woods
[15:00:07] <Jymmm> pfred1: You'll warm up fast running there then =)
[15:00:22] <JT-Shop> what happens depends on your G code and what offsets you have programmed
[15:00:42] <JT-Shop> G90 only does one thing
[15:00:43] <pfred1> JT-Shop offsets I have programmed?
[15:00:51] <JT-Shop> yes
[15:00:56] <pfred1> how do I program these offsets?
[15:00:58] <pfred1> this i new
[15:01:01] <pfred1> is new
[15:01:10] <pfred1> this is what I'm not getting
[15:01:21] <pfred1> or just am completely ignorant of
[15:01:22] <JT-Shop> when you set the XYZ offsets for the material
[15:01:57] <pfred1> I got the piece clamped down then I jogged around it and wrote down where the clamps are
[15:02:04] <JT-Shop> normally for me left edge is X0 back edge is Y0 and top is Z0
[15:02:10] <pfred1> so I don't try to go plowing through the clamps
[15:02:23] <pfred1> because that won't end well
[15:02:48] <pfred1> but besides the clamps i want to cut wherever else on this piece of test material
[15:03:05] <JT-Shop> of course your G code has to be written for the way you set your offsets
[15:03:32] <pfred1> well that's why I started out with absolute mode because it was easy to define the cutting space
[15:03:51] <jdh_> it is actually harder
[15:03:52] <pfred1> but figuring out Z in absoulute mode is tripping me up
[15:04:00] <pfred1> yeah I'm seeing thatn ow
[15:04:24] <JT-Shop> you need to set the G54 offsets for your material
[15:04:26] <pfred1> I guess I could go back and just write down the top of the material
[15:04:36] <JT-Shop> then you KNOW where everything is
[15:04:41] <jdh_> noz just touch off
[15:05:12] <pfred1> jdh_ tht's the way i always do Z is touch off I'm sketchier touching off X and Y though
[15:05:36] <pfred1> usualy i just make sure the clamps are no where near where i'm cutting
[15:05:53] <pfred1> so if i miss by a little bit no biggie
[15:06:36] <jdh_> I like Y0 on the front
[15:06:45] <JT-Shop> just move your tool to where you want X0 and Y0 to be and touch off
[15:06:47] <pfred1> OK thanks I think I see what I need to do
[15:06:54] <jdh_> but with a vise, it is simpler on back
[15:07:02] <pfred1> jdh_ my machine is weird I home it in the middle
[15:07:15] <jdh_> doesn't make any difference
[15:07:27] <pfred1> well Y0 I lose half my travel
[15:09:10] <pfred1> hmm i might stick with G90 for this and just figure out the absolute cuts on this particular piece
[15:09:46] <jdh_> you don't lose anything
[15:09:50] <pfred1> beause the exact depth isn't that critical I just want ot load the spindle up
[15:10:09] <JT-Shop> pfred1: you just need to configure your machine in a normal way
[15:10:24] <pfred1> JT-Shop how you figure?
[15:10:53] <pfred1> JT-Shop when i get a normal machine maybe I'll run it a normal way
[15:11:01] <JT-Shop> well you seem confused when we try to tell you how but your machine is set up in a weird way
[15:11:12] <jdh_> you can put home anywhere you want to that is physically accessible
[15:11:30] * JT-Shop goes back to work
[15:11:38] <pfred1> jdh_ true for me right in the middle seemed the simplest
[15:11:52] <jdh_> makes no difference
[15:11:53] <pfred1> but i know a lot of people home to the corner
[15:12:26] <jdh_> it sets you machine envelope, not your cutting coordinates
[15:36:06] <ToddZ> It makes no difference where the machine 0 is.
[15:36:34] <ToddZ> if your y has 12" of travel and machine 0 is smack in the middle
[15:37:04] <ToddZ> Then you touch off so G54Y0 is at machine -4"
[15:37:54] <ToddZ> you still have -2" of trave and +10" travel in the G54 system
[16:17:43] <srdc> Does anybody know if there is a HAL pin connected with the "Ignore Limits" checkbox on the GUI (Axis or GMOCCAPY)?
[16:18:36] <cradek> I'm pretty sure there is not
[16:18:57] <srdc> That's what I came up with searching - I couldn't find anything, anyway.
[16:19:08] <cradek> what problem are you trying to solve?
[16:19:13] <srdc> Here's my problem - I'm trying to button up the limit switches / homing on a VMC
[16:19:38] <srdc> It has 1 home switch per axis, which I am also using as a limit switch
[16:20:07] <cradek> ok so it's on one end of travel so you can get one direction of limits only?
[16:20:07] <srdc> We are using ClassicLadder in place of a physical PLC right now, with the notion that at some point we will probably install a dedicated PLC
[16:20:19] <srdc> So, CL handles the limit switches / eStop
[16:20:36] <srdc> I need to be able to tell CL that the user is requesting the limits to be ignored
[16:20:50] <srdc> I can do that in the GUI, but it doesn't do much good if the PLC isn't aware
[16:21:09] <cradek> I don't understand what you're doing to the switches with classicladder. can you elaborate?
[16:21:38] <srdc> Sure. CL reads the inputs directly from the limit switches (through a Mesa board)
[16:21:52] <srdc> If a limit switch is activated, it triggers the estop circuit
[16:21:52] <cradek> how do the switches work mechanically? are they at one end of travel?
[16:22:01] <srdc> Yes, they are at one end of travel.
[16:22:14] <pfred1> he wants a HAL pin that tracks the ignore limits setting
[16:22:40] <pfred1> srdc I know what you're saying
[16:22:41] <cradek> if a limit switch is directly tied to your estop, you can't home on it
[16:23:03] <srdc> I want a signal that can be used by CL (or a physical PLC) to temporarily override the limit switch.
[16:23:08] <cradek> pfred1: I understand that, but I'm trying to determine whether the reason he wants it is he's got things misconfigured
[16:23:22] <srdc> We have the logic in the ladder to override the limit switch.
[16:23:25] <pfred1> oh
[16:23:38] <srdc> The limit switch doesn't directly activate estop, it only does it through the PLC
[16:23:41] <cradek> normally in this situation a limit switch can be hooked to motion's limit input and also homing input.
[16:24:05] <cradek> then you configure the homing option to ignore the limit trigger
[16:24:09] <srdc> OK. That is an alternative.
[16:24:26] <cradek> no plc setup is needed, this is basic functionality
[16:25:20] <srdc> We had been trying to keep an imaginary separation so that all hard mechanical safety/machine-preservation functions are handled directly by the PLC (not a big deal now, but want to preserve this for a physical PLC)
[16:25:42] <srdc> Would there be a way to create a HAL pin tied to that GUI option?
[16:25:55] <cradek> it's very reasonable to want limit switches to be in the hard estop chain (made out of wires and contactors only, no computers)
[16:26:02] <cradek> in that case, you cannot home to it, of course
[16:26:28] <pfred1> I thought you could use limit switches as home switches?
[16:26:29] <cradek> if you want to enable jogging off of it, you must have a momentary button (real button and wires) to hold in that overrides the limit switch
[16:27:04] <cradek> but you've done something halfway in between these two setups
[16:27:48] <cradek> if you want limit switches in the (hard, made of wires) estop chain, install separate home switches or use index-only homing
[16:27:58] <Deejay> gn8
[16:28:15] <cradek> if you want to home to the switches you have, hook them to the limit and homing inputs and use linuxcnc's limit switch handling and override-limits features as-is
[16:28:20] <srdc> I understand that ...
[16:28:35] <srdc> But it seemed like a compromise of sorts was reasonable (like some VMCs are setup)
[16:28:44] <srdc> Where there is not an actual hard-wired override
[16:28:52] <srdc> But the override IS handled in the PLC, not the NC
[16:29:03] <srdc> Which would require a signal from the NC to the PLC to override it.
[16:29:18] <cradek> I'm not sure I understand all your goals and what you've done so far, but maybe you want to hard-wire a momentary override button
[16:29:22] <srdc> Or, more properly, instructing the PLC to ignore the limit switch input
[16:29:43] <srdc> That would work ...
[16:29:49] <cradek> linuxcnc already does what you want, but you are reinventing it in classicladder for some reason, and you don't have all the pieces you need
[16:29:57] <cradek> but I don't understand why you are doing that
[16:30:37] <srdc> Classicladder is just a standin right now for a physical PLC. All the inputs/outputs going to CL would be moved over to the physical PLC
[16:30:56] <srdc> Would there be a way to add a HAL pin mapped to that checkbox on the GUI?
[16:31:40] <cradek> of course it is technically possible for you to modify linuxcnc to have that
[16:31:50] <cradek> you could not do it without modifying linuxcnc
[16:32:25] <srdc> Directly? or would you think this could be done with a small comp or ...?
[16:32:32] <cradek> the as-is override limit behavior is very smart in linuxcnc
[16:32:50] <srdc> I understand that. I want to capture that.
[16:32:53] <cradek> if you override limits and it knows which limit you are on, it will only allow you to jog in the correct direction to fix it
[16:33:06] <srdc> I just don't want to rely on the hardware linuxcnc is running on
[16:33:46] <cradek> nope you cannot read the internal state of the AXIS gui with a comp
[16:33:55] <cradek> you would have to modify the AXIS gui
[16:33:59] <srdc> It's not really an enormous deal, more of trying to keep a principal of hardware separation, while compromising on limit switches that are already configured
[16:34:02] <srdc> OK
[16:34:07] <srdc> that's what I was wondering.
[16:34:43] <cradek> my vmc has the limit switches in the hard estop chain
[16:34:51] <pfred1> the whole point of LinuxCNC is LinuxCNC does it all
[16:35:18] <cradek> there is a recessed momentary button on the side of the control panel to override them, and that lets the machine come out of estop while it's held in. after you jog off the switch you can release it.
[16:35:27] <cradek> I have set this up on several machines
[16:35:45] <cradek> it is very simple and relies on no ladder/plc/computers
[16:36:08] <pfred1> cradek yeah but it relies on a skilled operator
[16:36:09] <srdc> That's probably the way we'll do it then.
[16:36:11] <cradek> it doesn't protect you from jogging the wrong way off the switch and hitting the end of travel
[16:36:39] <cradek> but the linuxcnc internal handling of limit switches does protect you from this
[16:37:01] <cradek> but it involves computers in the handling of the limit switches! you must pick one of the other, it's a tradeoff
[16:37:11] <srdc> I had just thought that if we could leverage LinuxCNC's elegance, while not having to add hardware, it would be pretty nice.
[16:37:40] <srdc> At any rate, at least I don't need to keep wasting time looking for it!
[16:37:46] <srdc> Thank you for the help!!!
[16:37:46] <cradek> :-)
[16:37:53] <pfred1> srdc a basic design goal of LinuxCNC is to not need external microcontrollers
[16:37:54] <sync_> cradek: it is not really smart
[16:37:58] <cradek> sure, hope it helped
[16:38:08] <srdc> cradek: always
[16:38:10] <sync_> there are a few mills that violate limit switches to change tools
[16:38:16] <sync_> it was relatively common back in the day
[16:38:41] <cradek> always tradeoffs
[16:38:43] <srdc> sync_ yep. Like this one. 1985 Mazak. But half of the limit switches were soft/NC-based
[16:39:05] <srdc> But then wired proximity switches once you were in the magazine.
[16:40:53] <srdc> pfred1 I do understand that. It is really nice to have those features. LinuxCNC is just so flexible, I had assumed that there would be a HAL pin for that signal, like there is for almost everything else. As machines get bigger, distributed tends to be safer - Mesa boards handling IO, PLC as safety watchdog, CPU handling motion calc/commands, etc.
[16:41:11] <srdc> Like I said, though, more a bigger deal in theory than principle.
[16:41:27] <sync_> cradek: you could just use a pilz safety plc trip the global estop after say .5s if the computer doesn't
[16:41:31] <pfred1> srdc LinuxCNC doesn't encourage some things
[16:42:29] <pfred1> it won't have a feature to make it easy for the end user to subvert basic design goals
[16:43:24] <srdc> pfred1 True, but I had thought a basic design goal was to a) not NEED external microcontrollers, but b) to ALLOW them as desired/helpful (think Mesa boards, PLC, etc) - LinuxCNC is meant to work well with PLCs.
[16:43:55] <pfred1> srdc mesa wrote drives for their boards
[16:44:00] <pfred1> drivers
[16:44:42] <srdc> pfred1 good point.
[16:45:10] <pfred1> so in doing that they can extend whatever they want
[16:46:20] <pfred1> but the core of LinuxCNC is developed by committee
[16:48:07] <pfred1> that committee is known to adhere to basic principals to a fault too
[16:48:24] <pfred1> which is why we love them
[16:49:41] <srdc> :D
[16:50:25] <pfred1> the whole why don't you support USB quesiton
[16:50:55] <pfred1> though the wiki has an interesting line at the end about USB3 now
[16:58:38] <Devilholk> Good evening folks
[17:00:48] <Devilholk> I am trying to build linuxcnc without rtapi since I can't build that part because of an undefined reference to sched_wait_interval among things. So I figured I could build it without that part by calling the configure script with the option --with-realtime=noauto but that didn't help (perhaps I just need to make clean though) but I may also be on a wild goose chase. Any suggestions would be appreacheated =)
[17:02:00] <Devilholk> after make clean one of the first thing that happens is that it lists c-files as "Depending" where it starts with the rtapi ones
[17:02:20] <JT-Shop> ./configure -help gives you a list of options
[17:03:53] <Devilholk> I guess I need to set --with-threads and --with-kernel since --with-realtime is deprechated
[17:04:08] <pfred1> Devilholk you using a kernel that works with RTAI?
[17:04:08] <JT-Shop> --with-realtime=PATH Path where RTAI is installed, or "uspace" for POSIX
[17:04:08] <JT-Shop> userspace.
[17:04:35] <JT-Shop> do you just want a simulator?
[17:05:36] <Devilholk> pfred1: I don't think so, I know it has preempt and I have made my own software using rt but it seems there is some preempt_rt that is different than rt on a standard preempt kernel (I am a bit fuzzy on this)
[17:06:01] <Devilholk> So I was aiming to build it for simulation for now since the docs say I can still drive motors but it will not be timing guaranteed
[17:06:11] <Devilholk> I have a SMP kernel btw
[17:06:16] <pfred1> Devilholk I've patched and built RTAI kernels and I know they only support a limited set of versions
[17:09:02] <Devilholk> It would be nice if I could build simulation only to begin with, this is what I have tried for now
[17:09:05] <Devilholk> ./configure --with-threads=posix --with-platform=raspberry --enable-drivers --enable-simulator --enable-run-in-place --with-python=python2
[17:09:20] <pfred1> I never did arm
[17:09:26] <Devilholk> (on a rpi3 running 4.4.41-1-ARCH #1 SMP (arch linux)
[17:10:31] <Devilholk> When the build process gets to rtapi a lot of warnings are generated, seems some header is missing but it compiles but linking fails later
[17:11:08] <pfred1> usually when a build errors out you can google the errir and find a solution
[17:11:09] <Devilholk> I don't fully understand if rtapi is mandatory for linuxcnc when running simulation mode but with motor driving
[17:12:02] <pfred1> I never did sim so I can't say
[17:12:19] <Devilholk> interesting.. now I got another error, a compilation error that seems to be regarding tcl, some struct that seems to differ codewise and headerwise (a member missing)
[17:15:26] <Devilholk> ok.. I need to dig in this, found a define that might help but need to figure out how to pass it to the gcc invocation in the makefile
[17:16:32] <Devilholk> -DUSE_INTERP_RESULT helped the TCL issue when compiling usr_intf/emcsh.cc so that's some progress =)
[17:18:23] <Devilholk> I also found a place in the configure script where "python" instead of "$PYTHON" is used to invoke the python interpreter
[17:19:30] <pfred1> python had better be on your path then
[17:19:52] <Devilholk> just "python" on this system is python3 instead of python2
[17:19:55] * pfred1 uses python all over his system so no biggie there
[17:20:22] <Devilholk> so the configure script has --with-python=something then $PYTHON is assigned something
[17:20:51] <Devilholk> So I use --with-python=python2 which worked mostly but in this one place in the configure script the variable $PYTHON is not used
[17:20:57] <Devilholk> instead "python" is hardcoded there
[17:21:40] <pfred1> Python 2.7.3
[17:21:46] <pfred1> /exec -o python --version
[17:22:51] <pfred1> anyone here into this site? http://www.homemadetools.net/
[17:23:24] <Devilholk> pfred1: I have both python2 and python3 installed, python is symlinked to python3, this is why I needed to specify that I wanted python2 since the python scripts used in the build process are for python2
[17:23:42] <pfred1> usually there's a switcher in distros
[17:24:03] <Devilholk> Yeah but now there is an environment var in the build script for this purpose, just that it wasn't used in one place
[17:30:44] <Devilholk> I mean one place in particular, it was used in loads of places =)
[17:38:22] <pfred1> Devilholk building projects is often not an easy task
[17:38:49] <pfred1> LinuxCNC isn't exactly Hello World
[17:38:50] <Devilholk> building projects you didn't make yourself* =)
[17:39:26] <pfred1> yeah I'm sure it built on the dev's systems just fine
[17:39:54] <pfred1> or they would have had al the troubles that you're having
[17:40:09] <Devilholk> Yeah but I am using an unusual system
[17:41:06] <Devilholk> Also, the very reason linuxcnc is most commonly distributed as a live image is probably because of the extra complicated build (with realtime stuff)
[17:41:19] <pfred1> yes indeed
[17:41:38] <pfred1> I'm just running a live install now myself
[17:41:44] <pfred1> but i have built it all in the past
[17:41:47] <Devilholk> hmm.. I think I used some weird git source for this
[17:42:03] <pfred1> the git repo should be fine
[17:42:03] <Devilholk> (I followed a guide aimed at my hardware but not at my distro)
[17:42:48] <pfred1> if I'm going to go through the trouble that's my source of choice
[17:43:14] <Devilholk> yeah, I think I was on a wilde goos chase
[17:43:36] <Devilholk> I didn't expect this to be a quick thing but I wanted to get some pointers in the general direction =)
[17:44:42] <pfred1> I spent like 3 weeks once building up a custom LinuxCNC system
[17:44:51] <Devilholk> oh the horror >.<
[17:45:09] <pfred1> I really spent some time stripping that kernel down
[17:45:12] <Devilholk> I was first planning on using a random PC I found but it basically hade zero interfacing capabilities (not even a SPP)
[17:45:36] <Devilholk> But then I for some reason thought linuxcnc would be easy to get running on an rpi so got one of those
[17:45:41] <Devilholk> And now I am messing about with that
[17:45:48] <pfred1> turns out there's no performance gain to be had doing that though
[17:46:33] <Devilholk> hehe
[17:46:35] <pfred1> I think x86 is still the easiest platform to run LinuxCNC on
[17:47:01] <Devilholk> yeah, no doubt
[17:47:16] <pfred1> well boot time can be reduced but the real system timing doesn't change
[17:47:35] <pfred1> that's hardware dependent
[17:47:51] <pfred1> Linux just works that good
[17:48:33] <pfred1> but I had to see it for myself because it doesn't make sense
[17:49:26] <Devilholk> I guess most bottle necks are IO related and not number crunching related
[17:49:46] <Devilholk> and number crunching power (optimization for native CPU) is what you get when you compile it yourself I guess
[17:49:47] <pfred1> it depends on the arch of the CPU
[17:50:08] <pfred1> some hardware is just faster
[17:51:43] <pfred1> fancy hardware that does a lot of speculative branching tends to fare worse
[17:51:53] <Devilholk> oh yay.. tkimg not availble for my arch.. or so the package maintainer says, maybe it is not true
[17:52:27] <pfred1> you should try to find a guide onine
[17:52:43] <Devilholk> Yeah but the guide is for debian based stuff
[17:53:57] <pfred1> I almost got LinuxCNC to work on Gentoo once
[17:54:02] <Devilholk> Nice
[17:54:10] <Devilholk> I almost got gentoo to boot without the installation CD once
[17:54:21] <Devilholk> But that was before I learnt arch so maybe I know more now and could get further ^^
[17:54:22] <pfred1> if I'd only known about the one kernel config I'd have had it
[17:56:10] <pfred1> on x86 RTAI needs some strange parameter set CONFIG_SPARSE_IRQ
[17:56:43] <pfred1> I don't even know what that is but if it isn't set it doesn't work
[17:57:08] <Devilholk> sparse irq.. sounds interesting but yeah.. no idea what it actually does =)
[17:57:17] <pfred1> well it only matters on SMP systems
[17:57:34] <Devilholk> seems tkimg is compiling just fine on this arch, just had to tell the package script that it works on this arch as well as x86_64
[17:58:11] <Devilholk> That trick works for most software that doesn't need to interface with specific hardware
[18:19:09] <Devilholk> it seems to be compiling now, I was following a deprechated guide I think
[18:19:30] <Devilholk> Not sure if it will be able to access the gpio yet but that is a later issue =)
[19:24:58] <Devilholk> ok, it works now, except it is a bit angry because I don't have a parallel port
[19:26:38] <Devilholk> There is a C source file for gpio for beaglebone.. trying to figure out if there is one for rpi and how I use it
[19:27:56] <Devilholk> grep only finds raspberry mentioned in the HostMot2 SPI driver in the hal dir that is
[19:30:20] <Devilholk> though hal_skeleton.c might be a good start..
[19:33:56] <Devilholk> I should sleep.. Anyway, thanks for a great project =)
[20:18:34] <R2E4> eveing all
[20:18:37] <R2E4> and morning all
[20:19:37] <R2E4> JT around?
[21:11:03] <MacGalempsy> well, the circuitboard for the smoothing circuit is printing at the moment. we shall see how it all comes out!
[21:26:41] <Wolf_> printing?
[21:34:10] <MacGalempsy> yeah, printing the plastic part, then going to cut this copper sheet for the connections
[21:34:32] <Wolf_> ahh weird
[21:34:53] <MacGalempsy> the sheet is .5mm, so I made it 7mm wide to get enough material to mimic 14ga
[21:35:06] <Wolf_> I wonder if you could do a layer of petg or something to use as etch mask lol
[21:35:17] <Wolf_> on bare pcb
[21:35:27] <MacGalempsy> probably, but just wanting to use wht I have on hand
[21:36:01] <MacGalempsy> so once the print is finished, I will cut the copper sheet to fit, then glue the two together
[21:36:19] <MacGalempsy> i'll post the stl on my thingiverse.
[21:37:23] <Wolf_> whats this thing you’re making?
[21:38:50] <MacGalempsy> this is the board for the smoothing circuit on the AC/DC transformer
[21:39:05] <MacGalempsy> http://www.thingiverse.com/thing:2029511
[21:39:21] <MacGalempsy> there are no images on there yet
[21:40:02] <MacGalempsy> its in the middle of printing in petg, so once its done, I will mock up the caps and resistor , then post a pic for you
[21:41:25] <MacGalempsy> the first one had supports for the caps, but since I could not get them to solder together very clean to 14ga, I decided to just put in a little more effort
[21:46:31] <MacGalempsy> well, the thingiview is available now. basically, it will hold 6 2200uf caps, a 5.1k/6.5W resistor, and a 1nF cap. it will have two sets of leads coming off the board, and din rail mounts