Back
[01:31:47] <huosen> CaptHindsight: thanks, any complete solution for a CNC known to be working well ?
[01:32:06] <huosen> seems that the link you passed, is just parts of it
[01:37:30] <ju-emb> that's the best of linuxcnc, you buy only the parts you need to make your machine run like you want
[01:41:45] <huosen> interesting
[01:42:02] <huosen> so i can adapt whatever complete solution i find on the martket to make it work with linuxcnc?
[01:42:16] <huosen> with the resources on that link
[01:42:17] <huosen> right?
[01:42:53] <ju-emb> what do you mean with complete solution
[08:45:06] <ju-emb> I try to get a c skeleton out of the rand component example
[08:45:08] <ju-emb> I copied the .comp file
[08:45:10] <ju-emb> give the component another name
[08:45:12] <ju-emb> and run comp myfile.comp
[08:45:14] <ju-emb> cd $home/linuxcnc/src
[08:45:16] <ju-emb> make
[08:45:20] <ju-emb> interesting part of the output is:
[08:45:24] <ju-emb> halcomp-srcs/hal/components/jgTestComp.c: In function ‘main’:
[08:45:26] <ju-emb> halcomp-srcs/hal/components/jgTestComp.c:93:8: error: expected ‘)’ before ‘;’ token
[08:45:28] <ju-emb> halcomp-srcs/hal/components/jgTestComp.c:95:1: error: section attribute cannot be specified for local variables
[08:45:32] <ju-emb> related lines in the .c file are
[08:45:36] <ju-emb> if(rtapi_app_main() < 0) return 1;
[08:45:38] <ju-emb> user_mainloop();
[08:45:40] <ju-emb> rtapi_app_exit();
[08:45:42] <ju-emb> return 0;
[08:45:47] <ju-emb> first line here is code line 93
[11:06:18] <cradek> ooh, new kgb looks a lot smarter about git
[11:06:34] <cradek> concerning large updates and merges
[11:11:57] <seb_kuzminsky> less floody?
[11:29:59] <cradek> I think so
[11:30:12] <cradek> I haven't managed to update it yet, though
[12:25:52] <kwallace> mhaberler: Rumor has it you might have some insight on the MDI queue. I'm finding when I feed MDI in a python UI script, I need to throttle a long list of blocks, but I don't know a good way to do this. Also if a routine crashes, it seems on the next routine run the remainder of the crashed blocks run and/or the new blocks use old numbered parameters. If you have any hints or links I would appreciate any help.
[12:26:10] <mhaberler> hi!
[12:26:28] <kwallace> Hello.
[12:27:19] <mhaberler> I had. This patch was reworked extensively/done differently by Seb; I dont really know what the current status of this is
[12:28:05] <kwallace> So I should talk to Seb about what changed?
[12:28:07] <seb_kuzminsky> hi guys
[12:28:13] <mhaberler> hi Seb!
[12:29:29] <kwallace> I have two problems. If I feed a bunch of blocks to MDI in Python I get errors about the MDI overflowing or some such.
[12:29:52] <seb_kuzminsky> ok
[12:30:40] <kwallace> Is there a good way to throttle the the feeding of the MDI queue, or should I need to?
[12:31:40] <kwallace> command.mode(linuxcnc.MODE_MDI)
[12:31:40] <kwallace> command.wait_complete() # wait until mode switch executed
[12:31:40] <kwallace> command.mdi('#100 = [#<_ini[AXIS_0]MAX_LIMIT> - #5221 - .001]')
[12:31:40] <kwallace> command.mdi('#101 = #5420')
[12:31:40] <kwallace> command.mdi('G38.3 X #100')
[12:31:40] <kwallace> command.mdi('G0 X #101')
[12:31:40] <kwallace> ...
[12:33:40] <seb_kuzminsky> you would write a wrapper around mdi() that does mdi() and then wait_complete(), maybe?
[12:34:55] <seb_kuzminsky> if you send too much mdi, at some point you *will* fill the buffer, no way around that
[12:35:11] <ju-emb> somebody any idea why the following code put into a .comp file doesn't compile on my machine?
[12:35:15] <ju-emb> component rand;
[12:35:17] <ju-emb> option userspace;
[12:35:21] <ju-emb> pin out float out;
[12:35:23] <ju-emb> license "GPL"; // indicates GPL v2 or later
[12:35:25] <ju-emb> ;;
[12:35:27] <archivist> pastebin
[12:35:27] <ju-emb> #include <unistd.h>
[12:35:31] <ju-emb> void user_mainloop(void) {
[12:35:33] <ju-emb> while(1) {
[12:35:35] <ju-emb> usleep(1000);
[12:35:37] <ju-emb> FOR_ALL_INSTS() out = drand48();
[12:35:39] <ju-emb> }
[12:35:41] <ju-emb> }
[12:35:47] <ju-emb> sorry
[12:36:09] <kwallace> seb_kuzminsky: I just stack the commands as you see above. I just have the one wait_complete because I copied it.
[12:36:25] <seb_kuzminsky> what's the error you get?
[12:37:09] <kwallace> kwallace or ju-emb?
[12:37:32] <seb_kuzminsky> heh, kwallace
[12:38:10] <seb_kuzminsky> is it just complaining about the mdi queue filling? if so i think it's working as it should
[12:38:53] <kwallace> Of course I don't have it handy, something about MDI full ... (10)
[12:39:23] <archivist> can one check buffer space before inserting
[12:40:04] <kwallace> So do a wait_complete after each command? I suppose it's easy to try.
[12:40:33] <seb_kuzminsky> kwallace: that should fix it
[12:40:39] <seb_kuzminsky> but archivist's suggestion is better
[12:41:15] <seb_kuzminsky> i don't know off the top of my head to ask the mdi queue if it's full, but if you figured out how to ask that you could do something like this:
[12:41:27] <ju-emb> http://pastebin.com/J8b41fNy
[12:41:31] <seb_kuzminsky> while mdi_queue_full():
[12:41:35] <seb_kuzminsky> sleep(0.01)
[12:41:44] <seb_kuzminsky> mdi("blah")
[12:43:30] <archivist> looking for complete means no joined up moves and stops between segments methinks
[12:43:57] <seb_kuzminsky> yeah, and i think that's ok and expected for mdi
[12:44:16] <kwallace> Okay I'll try, but sleeps seem to cause random long pauses so I have been trying to avoid them.
[12:46:05] <kwallace> Thank you, seb_kuzminsky, archivist .
[12:50:28] <kwallace> By the way, replaced my offending script and got:
[12:50:32] <kwallace> LinuxCNC interp_state change was INTERP_READING is now INTERP_IDLE
[12:50:32] <kwallace> maximum number of queued MDI commands exceeded (10)
[12:50:39] <kwallace> ...
[13:02:51] <mhaberler> there is a task.queued_mdi_commands value in the linuxcnc stat structure which should help; also a related INI parameter setting the maximum
[13:04:22] <kwallace> Yeah, I wasn't finding mdi_queue_full()
[13:05:08] <mhaberler> it should be status.task.queued_mdi_commands - good to send if less than limit
[13:05:51] <mhaberler> I forgot that on the NML dead body list: no queue backpressure mechanism or credit-based queues..
[13:09:42] <mhaberler> your credit of commands to send is ini [TASK]MDI_QUEUED_COMMANDS - stat.task.queued_mdi_commands (I think)
[13:21:30] <kwallace> Looking for [TASK]MDI_QUEUED_COMMANDS - stat.task.queued_mdi_commands with grep:
http://wallacecompany.com/tmp/mdi-1.txt
[13:24:45] <kwallace> Also, print "--> mdi ", status.task.queued_mdi_commands
[13:24:45] <kwallace> AttributeError: 'linuxcnc.stat' object has no attribute 'task'
[13:25:25] <mhaberler> hm.. you are using master?
[13:26:14] <mhaberler> oh, just use status.queued_mdi_commands - sorry
[13:31:14] <kwallace> mhaberler: I'll try status.queued_mdi_commands
[13:33:08] <kwallace> Yay, found it.
[13:34:32] <cradek> I thought you were going to write a file and run it with mdi O-call. that would work so easily.
[13:35:19] <mhaberler> or support multiline string MDI commands eventually
[13:36:11] <cradek> sure, but I mean something he can do right now that would instantly solve this problem he's been working on for weeks
[13:36:31] <cradek> lots of people are using mdi O-call
[13:38:48] <cradek> oh it's master? then I don't know if it works 100%, but I know 2.5 does
[13:39:17] <kwallace> Ah, uh... I think I meant to. One issue is that I need to interact with DROs in the UI.
[13:39:42] <cradek> howso?
[13:39:48] <kwallace> I'm using mostly 2.6.~pre
[13:41:35] <kwallace> For instance, I probe a face in X + direction, then display the location and have a button to zero the workspace or use the value for a calculation.
[13:43:23] <cradek> setting a zero on the edge is a really common task and should be one step - I don't understand what other kind of calculation you'd want to do?
[13:44:05] <cradek> in the touchy macros I use, you can specify which system to zero on the edge (default is the current one). this is easy to do with O-call because it can take parameters.
[13:48:28] <kwallace> I guess basically, I haven't worked out how to use the big O yet? If I were an inquiring student I suppose I should.
[13:50:14] <cradek> gcode quickref:
http://www.linuxcnc.org/docs/html/gcode.html
[13:51:04] <skunkworks> how would you sample and hold a bit? could I use an OR with its output fed back to the one of the inputs? something easier?
[13:51:07] <cradek> call by filename:
http://www.linuxcnc.org/docs/html/gcode/o-code.html#_calling_files
[13:51:53] <archivist> skunkworks, a latch
[13:52:19] <cradek> skunkworks: if you're in ladder, you might use edge triggered logic?
[13:52:33] <skunkworks> I could use ladder.. but hal?
[13:53:05] <skunkworks> flipflop maybe? there isn't a latch.. I thought maybe 'edge' but it doesn't seem to have a way to reset it easy
[13:53:28] <skunkworks> that I see anyway
[13:54:14] <archivist> a D flipflop is a latch
[13:54:36] <skunkworks> I see that. I think that will work
[13:54:37] <cradek> sample_hold doesn't do what you want?
[13:55:11] <skunkworks> that is for s32's
[13:55:14] <archivist> he said bit not analogue value
[13:55:18] <cradek> oh
[13:56:16] <archivist> one gets to
http://linuxcnc.org/docs/html/hal/components.html#_logic_and_bitwise_components_a_id_sec_realtime_components_logic_a
[13:56:51] <archivist> and then one cannot click flipflop to see its pins
[13:58:32] <cradek> it's a mistake to hardcode a list of components into the docs. those are autogenerated at the bottom of
http://www.linuxcnc.org/docs/html/
[13:58:40] <cradek> you can click on flipflop.9 there
[13:58:59] <skunkworks> right - that is where I am
[13:59:34] <kwallace> ju-emb: Your comp seems to compile and install for me. Did you remember to use "sudo comp --install my.comp_name"?
[13:59:59] <cradek> you could maybe also use mux2 with its output tied back to one input?
[14:00:17] <cradek> then it would either follow your input, or stay put
[14:00:37] <cradek> argh that's not a bit again
[14:00:38] <cradek> sorry
[14:00:40] <cradek> ignore me
[14:00:45] <archivist> that is what a d type does
[14:01:29] <archivist> and now I see its pins it has set and reset so does whatever is needed
[14:02:25] <archivist> I do not see why there is a mix of man style and html
[14:02:57] <archivist> as a user I expect html on the web :)
[14:03:15] <kwallace> By the way, what I'm playing with:
http://wallacecompany.com/tmp/probing_screen-11.png
[14:04:42] <cradek> archivist: oh don't go there
[14:05:14] <archivist> someone should as I think that is a cause of noobs annoyance
[14:05:51] <cradek> the only thing I've learned about that is that nobody's opinions are universal
[14:06:22] <cradek> some people think docs should be printed (from pdfs), some expect them on their own computer, some expect them on the web
[14:06:40] <archivist> I realise that but mixed is best of neither
[14:06:43] <cradek> we've stirred them all together with moderate success
[14:07:37] <cradek> most of those component docs are auto-generated by the comp program from markup in the comp files (or you get basic docs even with no special markup)
[14:07:45] <archivist> I have printed a set out waaaay back, but they go out of date, I like some form of consistency
[14:09:22] <cradek> kwallace: I don't understand how that screen is supposed to work by looking at it.
[14:09:56] <archivist> thinking of probing, I saw some camera driven stuff at a show yesterday, using focus and multiple grabs with height to get 3d models
[14:13:06] <kwallace> Press the small button to start the probe, say X+ starts moving in the + direction until it trips, then displays the X value. If you don't like the number you can clear it, if you want to use it as the current work space zero then press the origin button.
[14:13:39] <cradek> what does clearing it do?
[14:14:44] <kwallace> Nothing but clear the DRO. I find it reminds me not to use that number.
[14:15:16] <cradek> brb
[14:47:39] <kwallace> mhaberler: Do I need the .ini entry: [TASK]MDI_QUEUED_COMMANDS = stat.task.queued_mdi_commands ?
[14:48:00] <mhaberler> no, that defaults to 10
[14:48:45] <kwallace> I'm getting zero even when I get the MDI errors.
[14:49:07] <kwallace> --> mdi 0
[14:49:07] <kwallace> maximum number of queued MDI commands exceeded (5)
[14:49:59] <mhaberler> well again, this is what I started with, I dont know what happened to it
[14:50:10] <kwallace> print "--> mdi ", status.queued_mdi_commands
[14:50:35] <kwallace> I'm using 2.6~pre
[14:51:01] <mhaberler> I mean I did not have the last hand on this code, I would have to read up what happened
[14:53:36] <mhaberler> it seems Seb disabled this or didnt make use of this, so this might be dead code - you really should ask him, I'm just guessing
[14:53:43] <seb_kuzminsky> [TASK]MDI_QUEUED_COMMANDS is not used any more
[14:53:51] <kwallace> Oh and I had "[TASK]MDI_QUEUED_COMMANDS = 5" which seemed to produce (5) instead of (10)
[14:55:08] <kwallace> So checking for status.queued_mdi_commands in my loop does nothing?
[14:57:01] <seb_kuzminsky> i believe that's currently the case, sorry :-/
[14:59:02] <kwallace> No problem, sort of. So reseting my thinking... there is no way to check the number of queued MDI commands in order to pause the loading of more commands?
[15:01:51] <kwallace> If not, I guess I really do need to bone up on the O call, run from file business.
[15:10:22] <seb_kuzminsky> kwallace: you could do the waiting trick we talked about earlier (after each mdi command), or you could do the o-word named subroutine call that cradek suggested
[15:16:47] <kwallace> seb_kuzminsky: Okay, I'll try the wait_complete thing next.
[15:18:31] <kwallace> Cool, Suite Espanola on the radio.
[15:34:29] <seb_kuzminsky> kwallace: you're on master, right? look at tests/toolchanger/m61/test-ui.py, the LinuxcncControl class, the g() function
[15:34:39] <seb_kuzminsky> specifically it's handling of the 'wait' argument
[15:37:44] <mhaberler> hm, can you actually queue more than one mdi command? I wouldnt see how to detect an impending queue overrun
[15:39:30] <kwallace> seb_kuzminsky: I am not sure if we are using master or how up to date it is. I'll check test-ui.py.
[16:11:52] <cradek> jepler: since gremlin [?] all the View/Show... menu items are futzed
[16:12:17] <jepler> cradek: yeah that's been reported on the tracker
[16:12:22] <jepler> I haven't looked into it yet
[16:12:25] <cradek> oh ok
[16:12:30] <cradek> I haven't either, obviously
[16:14:58] <cradek> 2.5 is right
[16:15:00] <cradek> fwiw
[18:10:28] <kwallace> I haven't done a lot of testing but my MDI overfill problem doesn't seem to happen on the real mill configuration, but only on the sim.
[19:13:40] <cradek> KGB-linuxcnc: hey there, cowboy
[19:13:43] <KGB-linuxcnc> cradek: My master told me to not respond.
[19:15:56] <kwallace> KGB is sensitive.
[19:16:38] <KGB-linuxcnc> 03Root 05vfd-b-3 59c4195 06linuxcnc New branch with 30 commits pushed, 104 files changed, 031142(+) since vfd-b-3/9af287f
[19:17:03] <cradek> oh look at that, wooo
[19:17:17] <cradek> that's a lot nicer than the old flood.
[19:17:51] <cradek> seb_kuzminsky: ^^ !!
[19:21:01] <KGB-linuxcnc> 03Chris Radek 05kgbtest 1127259 06linuxcnc 03hi-there-kgb This is a test to poke kgb. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1127259
[19:21:27] <cradek> neat, it shows the user now, and handles new branches
[19:22:05] <kwallace> Upgrade?
[19:22:12] <KGB-linuxcnc> 05kgbtest 1127259 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1127259
[19:22:57] <cradek> yeah, I found a new version in a later debian repo and ported it. the site where I got kgb originally has disappeared. maybe it has new maintainers...?
[19:23:33] <kwallace> I hope it wasn't too much trouble.
[19:23:45] <cradek> it was actually pretty horrible :-)
[19:24:35] <kwallace> Oops.
[19:24:46] <cradek> but I have zfs, which conquers all (snapshot, try installing the terrible perl thing and see what it destroys, rollback)
[19:25:30] <cradek> it happily nuked all the config files, for instance
[19:25:36] <cradek> but no problem
[19:27:23] <kwallace> That reminds me of when, many years back when I had the patience, compiling kernels and forgetting that the config gets nuked.
[19:28:03] <kwallace> or rather the original config file
[19:28:11] <cradek> yeah, that was always lovely
[19:28:40] <cradek> today any OS without root on zfs is utterly second-class to me
[19:29:20] <cradek> I guess they call it the zeal of the converted
[19:32:51] <kwallace> Did you catch my comment above about my bad mdi program running just fine on real hardware?
[19:35:19] <kwallace> (trying O calls is still on my to-do)
[21:12:03] <seb_kuzminsky> cradek: thanks for fixing it :-)
[21:14:06] <ju-emb> On
[21:14:08] <ju-emb> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Build_A_Simulator_Manually
[21:14:12] <ju-emb> is a line that says:
[21:14:16] <ju-emb> The tcl8.4 and tk8.4 packages are only needed to get the dependencies check working, they will conflict with the configure. Remove them again.
[21:14:20] <ju-emb> sudo apt-get purge tcl8.4-dev tk8.4-dev
[21:14:24] <ju-emb> actually that's not needed anymore.
[21:14:26] <ju-emb> Y just tried and it compiled perfect on ubuntu 12.04
[21:16:19] <cradek> seb_kuzminsky: sure! so ok, now push all your bugfixes and let's see how it does
[21:16:44] <cradek> ju-emb: please do fix it if it's out of date! thanks
[21:17:06] <ju-emb> can I ?
[21:17:21] <cradek> ju-emb: yes, the wiki is editable by everyone
[21:17:55] <cradek> ju-emb: there's instructions for how to log in at
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BasicSteps
[21:18:22] <cradek> note that the name of our cute penguin mascot is chips
[21:19:02] <ju-emb> just reading it
[21:23:55] <skunkworks> http://www.youtube.com/watch?v=TH944Qq86kc
[21:29:39] <micges> wow, it's alive
[21:29:43] <skunkworks> sounds like they have smooth stepper sort of working - but that is it.
[21:29:58] <skunkworks> no printer port yet
[21:30:42] <skunkworks> A ton of - we will in the future be adding....
[21:31:28] <micges> iirc they are 1 year late atm
[21:31:43] <cradek> ha, 1 year is nothing in software
[21:31:56] <skunkworks> more than that...
[21:33:42] <skunkworks> cradek: I point to the article you found about - re-writing software from scratch...
[21:33:49] <ju-emb> There is no reason to be jealous with MACH, it's good to keep an eye on it, but it's really not 5% flexible as lcnc
[21:34:09] <skunkworks> jealouse? heh
[21:34:37] <cradek> I don't think anyone is jealous - they're pointing and laughing - which is also not particularly productive
[21:34:49] <cradek> but we all have hobbies
[21:34:52] <skunkworks> heh
[21:35:00] <skunkworks> It is better than reality tv...
[21:35:06] <cradek> mine is denigrating others' hobbies
[21:35:21] <skunkworks> what was the latest?
[21:36:10] <ju-emb> > It is better than reality tv...
[21:36:12] <ju-emb> OK, from that point of view, I agree
[21:38:22] <ju-emb> waht's a ngc file in the examples to see how a lathe config works?
[21:38:42] <cradek> lathe-pawn?
[21:39:08] <ju-emb> ok got it thank's
[22:18:47] <ju-emb> try to run /configs/sim/gladevcp
[22:18:49] <ju-emb> ImportError: No module named Xlib
[22:18:51] <ju-emb> what package is missing here?
[22:21:39] <micges> try libxlib-dev
[22:22:13] <micges> or simply libxlib
[22:23:41] <ju-emb> apt says no such packages
[22:25:01] <cradek> configs/sim/gladevcp/gladevcp_panel works for me
[22:26:17] <ju-emb> not for me, same error as the tab version
[22:27:11] <ju-emb> cradek: on what dsitro yours is running?
[22:27:41] <cradek> the mint that's based on ubuntu precise
[22:28:11] <cradek> you're surely just missing a package, but I don't know what it is
[22:28:22] <cradek> if you install with apt you'll get them all
[22:31:12] <ju-emb> python-xlib is the one missing
[22:31:14] <ju-emb> now runs panel but tab segfaults
