Back
[00:18:08] <CaptHindsight> zeeshan: will you be changing the spindle speed while cutting?
[00:18:16] <zeeshan> yes
[00:18:28] <zeeshan> mayube who knows
[00:18:29] <zeeshan> haha
[00:41:25] <zeeshan> 49hr
[02:45:52] <zeeshan> http://codepad.org/YqmMXKWL
[02:45:58] <zeeshan> i've been trying to figure this out for a wile.
[02:46:28] <zeeshan> if i do loadusr hf430.py , i do show pins, and i see the state of the drive is in no run mode.
[02:46:40] <zeeshan> when i run it manually through the control pad
[02:47:24] <zeeshan> the status does not change in show pins. but in my external driver "comms.py" , i can see a change of state of the drive. for some reason the hal pins won't update inthe loop?
[04:06:22] <zeeshan> nm. silly mistake
[10:20:02] <seb_kuzminsky> skunkworks: have you blessed rob ellenberg's current spiral arc branch?
[10:20:59] <seb_kuzminsky> i notice none of his commits have Signed-Off-By
[10:21:36] <skunkworks> seb_kuzminsky, not yet.. the last issue I have found is that if the first G0 move is the same as the current postion - it errors.
[10:22:37] <seb_kuzminsky> oops
[10:22:43] <seb_kuzminsky> does he know about that?
[10:23:17] <skunkworks> yes - but that was a day or 2 ago and I have not heard back.
[10:23:34] <seb_kuzminsky> ok
[10:23:39] <cradek> skunkworks: it's been months ago, but I saw a similar error if I issued a tool change when already in the tool change position (so move to tool change position is a null move)
[10:23:42] <skunkworks> that was his last 2 commits was trying to narrow it down.
[10:23:50] <skunkworks> cradek, exactly
[10:24:12] <skunkworks> cradek, what branch?
[10:24:29] <skunkworks> I wasn't getting it to do it in master..
[10:24:33] <cradek> it was some branch with the new planner
[10:24:40] <cradek> it was probably master at the time, before 2.7 branch existed
[10:24:51] <seb_kuzminsky> skunkworks: did it say "line can't have zero length!"?
[10:24:53] <cradek> oh good, maybe it's fixed then
[10:25:34] <skunkworks> seb_kuzminsky, yes - it does give an error in master - but in robs branch it actaully stops the program.
[10:25:45] <seb_kuzminsky> ok
[10:25:53] <seb_kuzminsky> i really appreciate you doing all this testing
[10:26:00] <skunkworks> The least I can do
[10:26:48] <seb_kuzminsky> i'm going to mail rob about the sob issue, i'll ask about the zero-length line and the tool-change from tool-change position too
[10:27:22] <skunkworks> heh - I just emailed him about an hour ago to see if he had a chance to look at it... :)
[10:27:46] <seb_kuzminsky> oh! then i wont bug him about it again
[10:28:06] <skunkworks> If I hear back I will then email him about the sob issue
[10:28:14] <seb_kuzminsky> that sounds good
[10:28:57] <skunkworks> THe zero length issue I don't think is as much about tool change as it is about the first 'rapid' move being at the same location as the current tool position
[10:29:41] <seb_kuzminsky> that sounds likely
[10:30:03] <seb_kuzminsky> you can point him at docs/SubmittingPatches for info about the sob thing
[10:30:51] <seb_kuzminsky> zlog:
[10:52:36] <KGB-linuxcnc> 03Mick 052.6 91467a6 06linuxcnc 10lib/python/pyvcp_widgets.py Bug in radio button pyvcp_widgets * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=91467a6
[11:34:27] <kwallace> I'm looking for an example of a serial numbering setup. I have an engraving application which uses TrueType Tracer to create the engraving g-code, but the problem is in running a number of parts with successive serial numbers, plus meet the requirement of having all the g-code done before hitting start.
[11:42:09] <cradek> interesting challenge
[11:43:54] <archivist> a classic for hand written code with loops, or access to a database to fetch/write serial numbers
[11:45:00] <cradek> yeah I assume you need serial numbers for some reason - getting that tracking worked out is the real challenge
[11:46:24] <cradek> getting the serial number gcode into the other gcode is the simple (but perhaps not easy) part
[11:49:24] <cradek> $ date +%s
[11:49:24] <cradek> 1421861329
[11:49:43] <cradek> this would be a great way to generate unique and monotonic serial numbers :-)
[11:50:17] <cradek> s/great//
[11:51:02] <cradek> assuming you make fewer than one widget per second of course
[11:58:05] <skunkworks_> does gene know that he can run linuxcnc without realtime?
[11:59:02] <pcw_home> Yeah wont sim run on just about anything?
[12:00:23] <pcw_home> if he wants realtime thats less invasive he should just build his own preemt-rt kernel
[12:02:05] <skunkworks_> I have not had any luck with nvida as far as realtime goes with wheezy.. Alteast on the hardware I have been playing with.
[12:05:13] <pcw_home> I wonder if the stock kernel works? you would think it would
[12:06:29] <skunkworks_> well - when I was testing (month or 2 ago) it ran just fine - just poor realtime performance. (even with pcie nvidea cards)
[12:06:49] <skunkworks_> with the stock neuvou or whatever driver
[12:09:47] <pcw_home> good reason to avoid nvidia
[12:10:54] <pcw_home> I think nvidia chipsets on MBs is a think of the past anyway
[12:11:02] <pcw_home> thing
[12:11:17] <seb_kuzminsky> intel seems to work well for me
[12:12:04] <pcw_home> Yeah intel built-in or chipset seems fine
[12:13:20] <pcw_home> I notice newer low cost MBs have intel MACs also, curious how they work with RT-Ethernet
[12:46:53] <Tom_itx> kwallace if you called each number from a sub you would have the code predefined for them
[12:47:10] <Tom_itx> just give it the offsets
[12:57:27] <seb_kuzminsky> call a custom m-code that runs a shellscript that runs truetype-tracer to generate a g-code subroutine file with the serial number, then call the newly generated subroutine to machine the serial number
[12:59:40] <cradek> oh yeah! we sure do have the equivalent of gcode include files
[12:59:52] <cradek> seb_kuzminsky's got the ticket right there
[13:02:12] <Tom_itx> programmer's perspective
[13:02:36] <cradek> what do you mean?
[13:03:26] <Tom_itx> his approach seems more like what a programmer would come up with
[13:04:23] <cradek> I don't understand. do you think it's inappropriate for him to give that advice?
[13:05:21] <cradek> I think it is likely to be very helpful to kwallace
[13:05:48] <cradek> and anyone who can write gcode to control a machine is exactly a programmer
[13:07:19] <cradek> oh I see you had a different suggestion
[13:07:32] <cradek> I don't understand how yours would work
[13:08:24] <cradek> I can see having one file per number, that you call to do the engraving, but I don't see how you would do the serializing
[13:09:12] <cradek> running tracer for each new serial number seems simpler to me, since it does the offsetting of subsequent numbers (with proportional spacing even)
[13:12:49] * seb_kuzminsky resists the temptation to come up with ever-more baroque contraptions for generating serial number gcodes
[13:14:49] <mozmck> according to the HAL manual, pins should not use underscores. But it looks like they work with underscores, so is that just a general convention for consistency?
[13:16:28] <mozmck> it looks like gladevcp widgets name the pins the same name as the widget, and underscores are common for that.
[13:16:30] <cradek> mozmck: yes it's bad to use a mix, so we picked one way. there's no technical reason for it.
[13:16:58] <mozmck> Ok.
[13:17:02] <cradek> I'm glad you read the manual and found that then :-)
[13:17:51] <mozmck> :) trying to read as much as I can! takes time it does...
[13:20:44] <mozmck> it seems like the docs here:
http://www.linuxcnc.org/docs/2.7/html/ do not include everything I see in the pdf I generated when I built the docs.
[13:21:23] <mozmck> I can't find the "General Reference" section in the HAL manual in the online docs.
[13:21:41] <cradek> uh-oh
[13:21:49] <mozmck> oh, I see it down under developer reference just as I typed that.
[13:22:01] <mozmck> "Developer Information"
[13:22:42] <seb_kuzminsky> there's a disconnect between how the html docs and the pdf docs are laid out
[13:22:51] <mozmck> I see that!
[13:22:54] <seb_kuzminsky> i fixed the Getting Started part, but ran out of steam for all the other parts
[13:23:57] <zeeshan> i cannot find an answer to this: when running a while loop in a python userspace component, what is the shortest time delay can be?
[13:24:14] <seb_kuzminsky> zeeshan: 0 seconds
[13:24:25] <zeeshan> how do you find what the actual delay is though?
[13:24:38] <seb_kuzminsky> time.time()
[13:25:28] <mozmck> you probably want to sleep() so it doesn't run too fast and hog the CPU don't you?
[13:25:56] <seb_kuzminsky> mozmck: yeah that's generally a good idea :-)
[13:25:59] <zeeshan> i am using sleep (0.01)
[13:26:08] <seb_kuzminsky> that seems like as good a number as any
[13:26:22] <zeeshan> but i'm not sure at what point becomes it becomes a nuisance on the realtime stuff
[13:26:43] <seb_kuzminsky> oh, it should never interfere with the realtime stuff
[13:26:49] <mozmck> that would depend on the computer, number of CPU's etc.
[13:27:01] <seb_kuzminsky> those things get the cycles they want, no matter what userspace is doing
[13:27:10] <zeeshan> seb_kuzminsky: okay good to know!
[13:28:24] <seb_kuzminsky> in realtime code you have to be careful to yield the cpu so the rest of the system can run, but in userspace all you do is make the UI stuttery and slow, the machine control isn't affected
[13:36:01] <mozmck> oh, yeah, this is not Mach :)
[13:38:03] <zeeshan> hahaha
[14:38:09] <zeeshan> i would really appreciate if someone can look over this code
[14:38:10] <zeeshan> http://codepad.org/zaVEzTH6
[14:38:30] <zeeshan> it is doing what i want it to do, but i feel like it's flooding the serial line
[14:38:50] <zeeshan> cause it defaults to "do not run" and keeps setting the frequency to the same value
[14:38:55] <zeeshan> for all 3 vfds
[14:39:17] <zeeshan> would it be better to use a statemachine?
[14:44:22] <PCW> you might only set the frequency if it changes
[14:44:55] <seb_kuzminsky> keep track of what the vfd knows, and only send it the info if it's changed
[14:45:42] <PCW> (clear knowledge if you get a comms error)
[14:52:44] <zeeshan> okay that makes sense. ill read the current drive freq, if it is not what hal pin is saying it to be, then it updates, else it doesnt do anything
[14:53:29] <zeeshan> i can extract if the drive is running/stop/forward from the drivestatus too
[15:02:01] <KGB-linuxcnc> 03Norbert Schechner 052.6 c240441 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_2 - bug in initializing lathe mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c240441
[15:02:01] <KGB-linuxcnc> 03Norbert Schechner 052.6 2fe3eab 06linuxcnc Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2fe3eab
[15:02:53] <KGB-linuxcnc> 03Norbert Schechner 052.7 6b1e3c8 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6b1e3c8
[15:04:02] <KGB-linuxcnc> 03Norbert Schechner 05master 4ceca76 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4ceca76
[17:39:44] <zeeshan> sorry mozmck
[17:39:52] <zeeshan> penguin doesnt work? :)
[17:40:09] <zeeshan> oh
[17:40:13] <zeeshan> whoops :)
[17:40:25] <zeeshan> tux doesnt work either
[17:40:32] <seb_kuzminsky> chips
[17:40:48] <zeeshan> thanks!
[17:52:14] <zeeshan> how can you post a some code on the wiki?
[17:52:19] <zeeshan> without it get parsed
[17:56:48] <JT-Shop> code tags
[17:57:26] <seb_kuzminsky> i think there's a link to the markup syntax on the BasicSteps page
[17:59:06] <zeeshan> <pre> </pre> worked
[18:54:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 87c3469 06linuxcnc 10src/emc/usr_intf/Submakefile 10src/emc/usr_intf/emcrsh.cc 10src/emc/usr_intf/schedrmt.cc remove some dead code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=87c3469
[18:55:01] <KGB-linuxcnc> 052.6-tcl8.6-fix c39a7f2 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c39a7f2
[19:03:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 e2cc274 06linuxcnc 10docs/src/hal/rtcomps.txt docs: remove an old FIXME * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e2cc274
[19:43:01] <skunkworks> seb_kuzminsky, this is what you are talking about for rob?
http://linuxcnc.org/docs/2.7/html/code/Contributing-to-LinuxCNC.html#_signed_off_by_policy
[19:43:53] <skunkworks> He just emailed me about the line cannot be zero length.. 'I think I know what's happening now. It turns out that canon allows moves that are 1.0e-7in long or greater. However, the posemath library assumes that a vector with magnitude 1.0e-6 is less is "zero" length. I was using this to check if a line was zero length, so posemath thought it was even though it was a valid (if short) move. The quick fix is to reduc
[19:43:53] <skunkworks> e posemath's "zero" vector declaration to 1.0e-07. I have no idea where the limit came from, but my guess is it wasn't rigorously chosen.'
[19:44:15] <skunkworks> he pushed a patch to his feature branch. I am testing it.
[20:23:58] <skunkworks> Wow - a machine with 1G acc and the new TP would be awesome... for what I don't know..
[20:26:06] <skunkworks> cutting air?
[21:32:39] <pcw_home> a fast router could easily have 1G accels a laser cutter even more
[21:39:16] <skunkworks> pcw_home, any questions for rob? he is on #linuxcnc at the moment... :)
[21:40:09] <pcw_home> Not that I can think of
[21:40:51] <skunkworks> seb_kuzminsky, I mentioned sob to rob and he is going to add it.
[21:41:08] <pcw_home> I dont recall seeing him here before
[21:41:27] <skunkworks> he gets on every so often - it has been a while.
[21:42:11] <skunkworks> we where emailing back and forth and finally told him he should get on irc.. he had forgoten about it ;)
[22:26:58] <seb_kuzminsky> skunkworks: yeah, that's the sob i was talking about, thanks for taking care of it
[22:35:47] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-01-21%2022:12:49.png
[22:36:03] <zeeshan> what in the world is that
[22:36:20] <skunkworks> lots of trajectory planner testing... :)
[22:38:13] <zeeshan> skunkworks: what does a trajectory planner do?
[22:38:22] <zeeshan> in terms of cnc machining
[22:43:02] <skunkworks> off the wiki.. Trajectory planning, in general, is the means by which EMC follows the path specified by your G Code program, while still operating within the limits of your machinery.
[22:46:09] <zeeshan> Hmm
[22:46:38] <zeeshan> will need to read about it
[22:46:42] <zeeshan> ive heard about it in terms of robotics
[22:46:51] <zeeshan> were you want to do different kinds of interpolation
[22:46:58] <zeeshan> just never in terms of g-code path plkanning
[22:47:09] <seb_kuzminsky> skunkworks: neat :-)
[22:47:12] <seb_kuzminsky> zeeshan: same idea
[22:47:21] <seb_kuzminsky> a cnc machine is a robot, after all
[22:49:03] <seb_kuzminsky> heh, spreadsheet2.ngc
[22:50:39] <skunkworks> I found out that the program that I found imported into a spreadsheet pefectly - I could then add <#scale> to all words..
[22:51:12] <skunkworks> and make the program any size I wanted
[22:52:51] <skunkworks> (I had to make it smaller to fit on the turco.. - it is this program..
https://www.youtube.com/watch?v=IkhlpdRWREE )
