Back
[05:43:19] <skunkworks> http://www.pmdx.com/PMDX-411
[05:43:53] <skunkworks> steves_logging: will this work with linuxcnc? ;) cool product.
[08:35:38] <cradek> > You are allowed to request replacement licenses for failed computers
[08:37:01] <skunkworks> from debian? ;)
[08:37:29] <cradek> no, sorry, I veered into the dark part of the web for a while there
[08:37:59] <skunkworks> heh
[08:39:55] <cradek> I like how carefully-worded that is. it makes no promises about whether you'll actually get to keep using the software you bought if your computer fails.
[08:40:04] <cradek> when
[08:42:21] <skunkworks> right
[08:45:36] <pcw_home> In my innocence I thought you were allowed to request anything
[08:47:58] <skunkworks> and it starts..
http://www.cnczone.com/forums/tormach-pathpilot-/261104-arc-radius-small.html
[08:51:21] <cradek> hmm, just mayyyybe he should've posted the snippet of gcode that errored
[08:51:41] <cradek> but he wanted to get some discussion going, instead
[09:01:19] <seb_kuzminsky> tell him to upgrade to 2.7.0~pre4, it increases the arc radius tolerance to the "your cam is sloppy" level of 0.0028 inches ;-)
[09:01:25] <skunkworks> Does 2.7 allow you to set the tollerence now? heh ok
[09:01:41] <skunkworks> can you change it?
[09:01:51] <skunkworks> (arc eyes changes (or whoever)
[09:01:52] <cradek> you can make it tighter than the default
[09:02:14] <cradek> the default works for gcode that is rounded to .001in or .01mm
[09:02:22] <seb_kuzminsky> i bet it's not in the docs though
[09:03:02] <cradek> IMO there's no reason to ever change the value from the default
[09:03:10] <skunkworks> agreed
[09:03:29] <cradek> I wonder how tormach is going to release updates. I understand they have eschewed normal debian packaging.
[09:03:44] <seb_kuzminsky> if you're working on very small parts and you want ther interpreter to tell you when you fat-finger the arc center/endpoints?
[09:04:09] <cradek> hm, maybe for edm of very tiny things
[09:04:21] <cradek> wonder what all gets weird if you do very tiny things
[09:04:42] <seb_kuzminsky> cradek: tormach updates?
http://fc07.deviantart.net/fs71/i/2014/084/2/7/w13_artifact__somebody_else_s_problem_field_by_lupinkurt-d7bl8az.png
[09:04:43] <cradek> I always make the mistake of only thinking about "normal" machining
[09:04:59] <archivist> I think small and avoid cam :)
[09:05:02] <cradek> seb_kuzminsky: haha "loose interest"
[09:05:17] <cradek> jeez
[09:05:22] <cradek> "loose interest in the feild"
[09:05:35] <seb_kuzminsky> the device is working well, clearly!
[09:05:42] <cradek> yargh
[09:05:46] <cradek> brb
[09:19:19] <skunkworks> http://api.viglink.com/api/click?format=go&jsonp=vglnk_142504911682717&key=8fc203c6d53cfcf639464b616dec43af&libId=i6np5leg010004q8000DAi61s7jb9&loc=http%3A%2F%2Fwww.cnczone.com%2Fforums%2Ftormach-personal-cnc-mill%2F259506-tormach-17.html&v=1&out=http%3A%2F%2Fwww.tormach.com%2Fuploads%2F897%2FUM10087_PCNC1100_BETA_5-7-pdf.html&ref=http%3A%2F%2Fwww.cnczone.com%2Fforums%2Ftormach-personal-cnc-mill%2F259506-tormach-18.
[09:19:20] <skunkworks> html&title=Just%20In%20Tormach%20News%20-%20Page%2017&txt=http%3A%2F%2Fwww.tormach.com%2Fuploads%2F897%2FU...A_5-7-pdf.html
[09:19:23] <skunkworks> uch
[09:23:33] <skunkworks> www.tormach.com/uploads/897/um10087_pcnc1100_beta_5-7-pdf
[09:24:16] <skunkworks> pcw_home, do you have a 'how to' for getting the latest -rt kernel?
[09:25:20] <pcw_home> https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
[09:29:17] <pcw_home> available patch sets:
[09:29:18] <pcw_home> https://www.kernel.org/pub/linux/kernel/projects/rt/
[09:32:11] <skunkworks> you used the 3.18.7-rt2?
[09:32:29] <pcw_home> I used rt1
[09:36:05] <skunkworks> huh - so linuxcnc really does have similar devices now (except usb) for 'motion devices..' The 7i92 is pretty close to ethernet smooth stepper
[09:36:26] <skunkworks> (other than 1000 times better :) )
[09:42:52] <pcw_home> well maybe not 1000 times better...
[09:42:54] <pcw_home> better because all the complex bits are in linuxcnc/hal where they are easy to get to and debug
[09:44:16] <skunkworks> I think ESS is in effect 3 printer ports.. but the 7i92 has a lot more expandablillity..
[09:46:08] <pcw_home> I have gotten so spoiled by having all pins interchangeble and not having to deal with dumb ucontroller peripherals That I dont think I could ever go back
[09:49:45] <pcw_home> (to ucontrollers vs FPGAs)
[09:49:46] <seb_kuzminsky> skunkworks: wow, that's a great introduction
[09:50:29] <skunkworks> they go into o-words also... kinda neat
[09:58:33] <pcw_home> micges_: latest patch fixed the g1 errors
[10:00:04] <cradek> Grab the Maxvel slider again and slowly increase the allowed velocity (see Figure 5.10). Bring
[10:00:07] <cradek> the velocity back down to zero when you get close to the part and double check the values
[10:00:10] <micges> pcw_home: that's good
[10:00:10] <cradek> in the DROs.
[10:00:11] <cradek> YES
[10:00:36] <cradek> this is very clueful
[10:01:21] <micges> pcw_home: I've just back from real machine testing
[10:02:12] <micges> skunkworks: found few minor bugs but arcs and blending works, later I'll push changes to repo
[10:03:45] <micges> machine at 60m/min / 1g acc ad 100k jerk have ultra smooth path even on g1/g1 at 170 deg angles
[10:05:31] <pcw_home> I noticed an improvement in stepgen performance (lower ferror magnitudes)
[10:05:32] <pcw_home> limited jerk papers over the fact that the accel used for feed forward is 1 cycle late
[10:07:38] <micges> how so 1 cycle late?
[10:08:14] <micges> I saw everywhere current pos - latest pos to calc curr vel
[10:09:06] <pcw_home> because its done in hal with differences of velocity
[10:09:26] <micges> right
[10:10:08] <cradek> now that I'm on page 84 I see they've totally forked the documentation too. wow they've bitten off big chunks.
[10:13:45] <cradek> > The parameter values are absolute machine coordinates in the native machine units of inches.
[10:13:57] <cradek> huh are they selling only inch machines?
[10:14:18] <pcw_home> thats... odd
[10:14:26] <skunkworks> micges, 30in/s^2 with >100 causes all kinds of violations... If I up the acc to 400in/s^2 errors go away...
[10:15:07] <pcw_home> 1G is where to be
[10:16:03] <micges> yeah code is only for fast machines ;)
[10:16:13] <skunkworks> heh
[10:16:19] <micges> skunkworks: thanks I'll check it too
[10:17:27] <skunkworks> well 400in/s^2 and 100k jerk also has a ton of violatoins.
[10:18:13] <pcw_home> skunkworks: did you pull the latest
[10:18:20] <skunkworks> yes
[10:19:13] <micges> skunkworks: redirect output to a file and send me one when this violations occurs
[10:19:31] <skunkworks_> v2.7.0-pre4-88-g598b5f6
[10:20:29] <cradek> they removed mention of coordinate system rotation
[10:20:35] <skunkworks> saw that.
[10:21:20] <skunkworks> they also do some funky stuff like - if you run a program in mm - it keeps that setting until you run gcode explicitly changing it.
[10:24:34] <cradek> I guess we don't have to agree with each of their changes, do we
[10:25:13] <cradek> we'll have some benefit (yay rob!) and some fallout (users complaining to us about PP-specific bugs), but it'll be fine
[10:25:27] <cradek> so far, the benefit really outweighs
[10:27:23] <skunkworks> right
[10:27:40] <pcw_home> Thats certainly my impression (not sure the people that complained about Tormach have any idea how much work is involved in the TP changes)
[10:28:43] <cradek> who's even complaining?
[10:29:20] <skunkworks> people have strong opinions that tormach 'stole' linuxcnc
[10:30:42] <skunkworks> cradek, read through some of the comments..
https://www.youtube.com/watch?v=WqJmBEWnvpk
[10:31:20] <skunkworks> micges, sent you an email
[10:31:34] <cradek> I can't. it's too early in the day for youtube comments.
[10:31:48] <skunkworks> heh
[10:32:06] <cradek> also, I don't really care what you-tubers think
[10:33:17] <cradek> tuber /tu.ber/ (too'ber) pl. tu'bera, tubers: 1. a swelling or protuberance
[10:33:40] <cradek> 2. a knoblike localized swelling
[10:33:45] <cradek> hahaha
[10:33:47] <cradek> knoblike
[10:34:10] <skunkworks> it sounds like it isn't too early for you.... :)
[11:40:05] <cradek> what on earth:
http://linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28910-make-own-linuxcnc
[11:42:10] <archivist> erm hard to think up a polite answer for that
[11:42:34] <seb_kuzminsky> "please go study everything for 1 year, then come back with any questions you have"
[11:43:47] <skunkworks> so what current os would run decently on a pentium m laptop with 256mb..
[11:44:11] <archivist> assembler OS
[11:44:34] <skunkworks> with a gui...
[11:44:58] <cradek> I have our debian install running on a 256MB P3 machine, running my lathe
[11:45:03] <cradek> it's a little tight but ok
[11:45:21] <seb_kuzminsky> that's cool
[11:45:25] <cradek> what do you want to do on it? probably no good for web browsing
[11:45:32] <seb_kuzminsky> i didnt realize x still fit in 256 mb ram
[11:45:49] <archivist> Yggdrasil Linux would just about too
[11:45:51] <cradek> it's surprisingly fine. wouldn't want to fire up iceweasel though
[11:46:07] <skunkworks> yah - that would be the deal.. I might just have to say I don't have anything that will work. (owner wants to repurpose her old laptop for a reletive)
[11:46:49] <archivist> put win 3.11 on it then
[11:46:58] <skunkworks> she wants to facebook
[11:47:09] <archivist> not on that machine
[11:47:11] <skunkworks> that is a verb now - right?
[11:47:13] <cradek> nah
[11:47:23] <cradek> just add some ram and it'll be fine
[11:47:57] <cradek> also, getting relatives hooked on facebook is a disservice to humanity and you shouldn't help with it
[11:48:11] <archivist> one needs to max out the ram for "modern" web sites
[11:50:53] <seb_kuzminsky> install elinks for he
[11:50:56] <seb_kuzminsky> *her
[12:13:41] <mozmck> haha! +1 cradek
[13:08:57] <andypugh> Sometimes I don’t understand the question:
http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28910-make-own-linuxcnc
[13:10:12] <cradek> yeah we puzzled over that one earlier
[13:10:28] <archivist> polite answer or what
[13:43:54] <cradek> archivist: you did great.
[13:44:32] <cradek> oh wait that was andy
[13:44:35] <cradek> andypugh: you did great.
[13:44:37] <archivist> where what? I did nothing
[13:44:56] <cradek> well, we're all great, to some extent
[13:45:50] <archivist> and now the polite reply, windows is not realtime and will not drive machines well
[13:46:27] <cradek> not why do you think anyone would want to help you with that?
[13:50:45] <Tom_itx> wtf were you thinking anyway??? more appropriate
[13:52:32] <archivist> reminds me of the "If I wanted to get there I would not start from here" quip
[16:01:08] <seb_kuzminsky> CaptHindsight: did you see andypugh's slice viewer? sounds like what you and i were talking about the other day.
[16:01:11] <seb_kuzminsky> https://www.youtube.com/watch?v=ChKmIHP7G_U
[16:02:11] <CaptHindsight> oh, that is new
[16:03:25] <CaptHindsight> andypugh: I want to get Linuxcnc to support SLA DLP/LCD printers including handling the SVG's to the projector
[16:04:52] <andypugh> You can pretty much consider that done :-)
[16:05:32] <andypugh> I am impressed by the speed. Especially as that is running in a VM on my Mac.
[16:06:04] <andypugh> 67 lines of code
[16:07:10] <andypugh> I would like to find a way to add the Z-height without having to define my own xmal namespace
[16:08:10] <andypugh> Currently I have to grab the Z-height with “ Z = node.get(“{
http://www.bodgesoc.org}Z”) which seems silly.
[16:08:57] <andypugh> The SVG file has “slicer:Z” but xml.etree expands the namespace :-(
[16:09:09] <CaptHindsight> andypugh: where is this hosted?
[16:09:43] <CaptHindsight> and how does it work with the gcode? An Mcode for the images?
[16:10:57] <andypugh> It isn’t hosted anywhere at the moment.
[16:11:08] <andypugh> It’s something I am playing around with for a friend.
[16:11:54] <CaptHindsight> the next step is to have synchronized motion of other axis during printing, placing inserts, lasers, printheads etc
[16:12:03] <andypugh> There is some VBA code that creates and SVG file from inside Autodesk Inventor, and then a Realtime HAL component that displays the slice that is passed to it on a HAL pin as a Z-height.
[16:13:14] <andypugh> Sorry. NOT a Relatime HAL comp. a USERSPACE HAL comp
[16:15:17] <andypugh> CaptHindsight: Or you can do it all inside the SVG file, this one here has an embeded script so you get whatever slice you append to the URL:
http://www.bodgesoc.org/newfile_script.svg?5
[16:16:24] <andypugh> (If you View Source you will see the XML tags I am using in the SVG)
[16:16:29] <CaptHindsight> it needs to be part of Gcode
[16:17:03] <andypugh> I don’t understand Why, or how, it can be a part of G-code.
[16:17:52] <andypugh> What is wrong with linking a random Axis to the slice height required?
[16:18:04] <andypugh> Or using the G-code analogue output?
[16:18:50] <andypugh> (I haven’t worked out how to choose the input file yet, currently it’s a command-line parameter)
[16:19:37] <CaptHindsight> how do you introduce other operations and motions between displayed slices?
[16:20:32] <andypugh> I probably need to add a blanking pin.
[16:20:54] <andypugh> (Possibly even an exposure-time pin)
[16:20:55] <CaptHindsight> you also want to set the duration of the image on the projector, the blank time before and after Z motion
[16:21:50] <andypugh> I am just messing about at the moment, I have never even seen a DLP printer.
[16:22:22] <andypugh> But I can iagine that the exposure and blanking might be better done in hardware.
[16:23:31] <andypugh> How critical is the exposure time? Is userspace latency likely to be good enough?
[16:24:10] <andypugh> Currently my “customer” is using a Windows PC to display the images, so it can’t be that critical.
[16:24:27] <CaptHindsight> it's very critical
[16:25:16] <CaptHindsight> the exposure time and the time after exposure before you tilt the build surface and after
[16:27:06] <andypugh> I can’t see it being possible to parse and display SVG in the realtime threads.
[16:27:50] <CaptHindsight> a single layer might go like this: move Z, move wiper over surface, wait 1 sec, display image for 0.8 sec, scan printhead XY over surface, scan laser XY over surface, move Z .....
[16:28:01] <andypugh> But I guess the question is whether exposure is critical to the microsecond or millisecond.
[16:28:36] <CaptHindsight> or move a robot arm over the exposed print and place an insert at a given layer
[16:28:56] <CaptHindsight> 0.1 sec for now
[16:29:40] <andypugh> I think that even Userspace can manage that.
[16:30:11] <CaptHindsight> for a scanning laser it's like cutting speed only in the several meters per second
[16:30:30] <andypugh> So, I could add an exposure-time pin and a “show now” input pin and “exposure over’ output pin.
[16:31:23] <andypugh> This is all just implementationdetails.
[16:32:19] <andypugh> I was only really trying to see if it is possible to have every layer in one SVG file and handle it in reasonable time.
[16:32:29] <andypugh> How many layers in a typical part file?
[16:32:42] <CaptHindsight> anywhere from a few to several thousand
[16:33:08] <andypugh> I guess I should try a more compley model and many more layers.
[16:33:20] <CaptHindsight> if you're printing a part 100mm high with 100um layers, 10K
[16:33:33] <CaptHindsight> well you're ahead of me on the Linuxcnc end
[16:33:44] <andypugh> Does anyone use adaptive layer heights? (there is no point having 1000 identical layers in the SVG)
[16:34:09] <CaptHindsight> sorry meant 10um
[16:34:26] <andypugh> Do you know if there is an accepted standard for the multi-layer SVG file format?
[16:34:41] <CaptHindsight> if you slice it asymetrically then yes you need to print it that way as well
[16:34:56] <CaptHindsight> no
[16:35:28] <CaptHindsight> the software is either closed by the corprate players, or a train wreck by the reprappers
[16:35:35] <andypugh> Not necessarily. My HAL comp chooses the layer closest to the current Z height, so you coulf have two slices 100mm apart and then 1000 slices in the next mm and it would work.
[16:36:17] <andypugh> CaptHindsight: Did you look at my SVG File? (Ignore the script at the beginning)
[16:36:44] <CaptHindsight> the image for each layer just has to match the actual printed Z location/height
[16:37:10] <CaptHindsight> http://www.bodgesoc.org/newfile_script.svg?1
[16:38:00] <andypugh> No, I don’t think there should be any requirement for an exact correspondence between SVG layers and exposure heights.
[16:38:14] <CaptHindsight> I guess you could have some run length encoding to get rid of redundancy
[16:38:57] <CaptHindsight> i think this is getting lost in translation
[16:39:00] <andypugh> The SVG just needs to have a height attribute for each layer, and the printer chooses the best layer to suit the current printer height.
[16:40:02] <andypugh> My friend is currently slicing every 5um, then exposing 5 frames in sequence every 25 um
[16:40:49] <andypugh> Hmm, perhaps between layers I should display two layers at 50% Alpha?
[16:41:05] <andypugh> (Or, indeed, at proportional Alphas)
[16:41:23] <CaptHindsight> one frame every 5um or 5 different frames at one Z position being every 25um?
[16:41:57] <andypugh> He has SVG slices for every 5um, but he only moves the X every 25um
[16:45:39] <CaptHindsight> ok, so move Z 25um, display image 1, 2, 3, 4, 5, move Z 25um, display 6, 7, 8, 9, 10 etc
[16:45:58] <andypugh> Yes.
[16:46:08] <andypugh> Sort of physical anti-aliasing
[16:46:47] <CaptHindsight> yeah I get it
[16:55:33] <CaptHindsight> coordinating motion with a printhead or a projector is another project
[16:56:32] <CaptHindsight> the projector might scan over over an area XY syncing video with motion, similar to a printhead
[16:58:09] <CaptHindsight> or use a galvo to steer images from a single projector onto a larger surface
[17:04:20] <PCW> Not sure why they dont use laser scanners from a printer
[17:04:22] <PCW> seems like it woudl be cheaper and better than galvos (though wastes energy like the DLP)
[17:06:21] <CaptHindsight> some do, it's a big patent mess
[17:07:12] <PCW> all of 3DP is a patent mess
[17:09:23] <CaptHindsight> most of the SLA and DLP printers are slow and used for protos or trinkets
[17:14:29] <andypugh> CaptHindsight:
https://github.com/andypugh/SVG_Slicer
[17:15:09] <CaptHindsight> andypugh: thanks, I'l try it
[17:20:14] <andypugh> I can imagine www.bodgesoc.org accidentally becoming the default namespace for SVG slicers. That would be silly.
[17:20:34] <andypugh> And I have an early start tomorrow, so will be off now.
[17:27:29] <seb_kuzminsky> hey dgarr
[17:27:45] <dgarr> ?
[17:28:04] <seb_kuzminsky> naw, that's it, just hello
[17:28:23] <dgarr> oh, hi
[17:28:42] <seb_kuzminsky> heh
[17:28:54] <skunksleep> seb_kuzminsky: did you see the email from rob?
[17:30:55] <seb_kuzminsky> i saw it
[17:31:04] <seb_kuzminsky> i started adding a g33.1 test to the sam branch
[17:32:29] <seb_kuzminsky> i didn't make that branch name-collide with you on purpose :-/
[17:36:24] <skunkworks> :) not a problem
[17:37:12] <skunkworks> my name is capitalized...
[17:37:35] <seb_kuzminsky> whew, so we'll still be able to tell the difference between you and a branch head in our git repo
[17:40:57] <skunkworks> thank goodness..
[17:46:19] <PCW> skunkworks: your drunkards dream gcode seems to run fine here ( 4KHz 2400 IPM ~1G)
[17:50:04] <PCW> not sure I would want to try running that on an Atom
[17:54:46] <micges> PCW: I have problem with terminal output on atom with rt-preempt and 1kHz :)
[17:55:40] <PCW> Not terribly surprising...
[17:55:54] <skunkworks> micges: did the terminal output make sense?
[17:56:05] <skunkworks> pcw: awesome!
[17:56:47] <PCW> stock 2.7 of course
[17:56:50] <Tom_itx> is the J1800 performance alot better than the D525?
[17:56:57] <skunkworks> yes
[17:57:03] <PCW> Yes about 2/3x
[17:57:17] <Tom_itx> even the mini-itx board?
[17:57:23] <PCW> Yes
[17:57:24] <Tom_itx> i suppose they're the same just no PCI
[17:57:28] <micges> skunkworks: yes
[17:57:35] <PCW> some have PCI
[17:58:18] <micges> there is problem with converting calculated time to servo cycles count, float point once again
[17:58:37] <micges> skunkworks: I working on this
[17:58:49] <skunkworks> nice!
[17:59:27] <micges> skunkworks: with this error you have at least one servo cycle too much at max speed so it leads to overshoot position at end and violations vel/acc
[18:01:48] <PCW> d525 is ~2 beaglebones J1800 is ~4 G3258 is ~16
[18:05:19] <PCW> e8500 core duo is ~8
[18:05:40] <Tom_itx> all 4 run lcnc good?
[18:05:51] <PCW> Yes
[18:06:20] <PCW> Well D525s are awfully slow
[18:07:25] <Tom_itx> i wouldn't know the difference on this sherline
[18:08:34] <PCW> if you use a fancy gui or image2gcode or something you will notice
[18:12:07] <PCW> or run a servo thread much faster than 1 KHz or a big classic ladder confg...
[18:35:08] <KimK_laptop> PCW: Where would an E350N fit in your beaglebone scale above? (I'll leave it to you to specify which flavor of E350N, if needed.)
[18:43:50] <PCW> Its pretty close to the J1800
[19:22:53] <Tom_itx> i think it would be prety difficult to put this pcie card in the D525 board
[19:22:59] <Tom_itx> unless i'm missing something
[19:23:18] <Tom_itx> however the J1800 looks pretty inviting..
[20:01:19] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk ebf4648 06linuxcnc 10(8 files in 3 dirs) bring back old trajectory planner and use it in motion * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ebf4648
[20:01:19] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 1d1a538 06linuxcnc 10(10 files in 4 dirs) jerk_tp: introduce [AXIN_n]MAX_JERK parameter and forward it to task and motion * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1d1a538
[20:01:19] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 4986cef 06linuxcnc 10(10 files in 4 dirs) jerk_tp: calculate jerk for all linear moves in canon and forward it to tp * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4986cef
[20:01:22] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 40e353f 06linuxcnc 10src/emc/jerk_tp/jerk_tc.h 10src/emc/jerk_tp/jerk_tp.c jerk_tp: Implement the S-Curve Acceleration with FSM in trajectory planner * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=40e353f
[20:01:27] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk a0db329 06linuxcnc 10scripts/platform-is-supported disable rtai buildbot for now * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a0db329
[20:01:31] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 36471dd 06linuxcnc 10tests/halui/mdi/halui.ini update runtests * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=36471dd
[20:01:34] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk ccd385b 06linuxcnc 10src/emc/jerk_tp/jerk_tp.c jerk_tp: show proper velocity in DRO and use required vel not max vel in jerk calculations * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ccd385b
[20:01:39] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk a2181a3 06linuxcnc 10src/emc/jerk_tp/jerk_tp.c jerk_tp: fix calculations when we got tiny values for stages cycles count * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a2181a3
[20:01:43] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 74ae0ee 06linuxcnc 10src/emc/task/emccanon.cc jerk_tp: temporary use ini max jerk in ARC_FEED for arc moves testing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=74ae0ee
[20:02:28] <micges> skunkworks: PCW: arcs works
[20:12:38] <PCW> Great Ill try running some code now
[20:49:50] <Tom_itx> pcw_home, how much ram were you running in the J1800 boards?
[21:41:40] <pcw_home> 2G I think
[21:42:12] <pcw_home> and AFAICR the PP works at least in EPP mode
[22:19:53] <Tom_itx> i wonder if that ASRock Micro ATX would run off one of those PICO PSU120s
[22:20:26] <Tom_itx> i've been running this pc off one 24/7 for several years
