Back
[09:38:27] <almost_bold> jepler are you there?
[09:41:20] <almost_bold> In control.c, function static void process_inputs(void)
[09:41:32] <almost_bold> we have access to "joint->pos_cmd"
[09:41:58] <almost_bold> if I force this value to lets say joint->pos_cmd = 100;
[09:43:00] <almost_bold> the change is not seen outside the scope of the process_inputs(void) function. I believethat it is related to the fact that joint is pointer.
[09:43:23] <almost_bold> How can I make the "source" of the pointer to contain the required value?
[09:51:21] <seb_kuzminsky> almost_bold: the -> operator dereferences the pointer and lets you access the stuff it points to
[09:51:26] <seb_kuzminsky> your syntax is right
[09:51:27] <seb_kuzminsky> but remember:
[09:51:41] <seb_kuzminsky> 'joint' is just one joint, there's a whole array of them
[09:53:25] <seb_kuzminsky> also, joint info is kept in several places
[09:53:38] <seb_kuzminsky> there's the hal pin values that process_inputs() deals with, that you found
[09:54:04] <seb_kuzminsky> also look at update_status(), which has the "status buffer" copy of joint info, which is what Task and Interp and most UIs look at
[09:54:17] <seb_kuzminsky> bbl
[09:56:16] <almost_bold> status seams promising... thank you, will try to dig more information.
[10:38:28] <seb_kuzminsky> almost_bold: what's your goal? i feel like i'm missing some context, the motivation for these changes
[11:44:33] <jepler> seb_kuzminsky: I think this pertains to the proposed switch-between-C-axis-and-spindle feature we were discussing the other day with "emcPT" though that's just a stab in the dark; I'm not aware whether emcPT and almost_bold are connected
[11:54:46] <cradek> this is one of those problems where it's easy to underestimate the number of layers involved
[12:03:35] <almost_bold> Yes we are. A few guys knowing a bit of programming and a bit of machining
[12:03:44] <almost_bold> and getting bold
[12:03:54] <cradek> bold is great
[12:03:56] <seb_kuzminsky> heh
[12:04:45] <almost_bold> I don't think so. My wife don't think so also, except on the bathroom where I leave less mess.
[12:05:01] <almost_bold> (less hair)
[12:06:13] <almost_bold> Back to subject. We are here for more than 2 days. A bit of mechanical issues and programming and we feel that we are so close, but at the same time something not obvious for us is missing.
[12:06:56] <almost_bold> Our try is with the following per misses and those are working:
[12:07:27] <almost_bold> a) created a new pin on axis 5 that is C axis, that is called caxis_enable
[12:07:44] <almost_bold> b) this pin we can place it true or false using a hal command
[12:08:04] <almost_bold> c) the following code enters in the if when the user sets it to true:
[12:08:48] <almost_bold> if (joint_num == 5 && joint->caxis_enable == 1) // Joint is number 5 and it is in spindle mode
[12:08:49] <almost_bold> {
[12:08:49] <almost_bold> joint->pos_cmd = joint->pos_fb;
[12:09:22] <cradek> like jepler told emcPT, you need to start at the other end and have a gcode that switches modes, then that tells task to resync, and task tells motion
[12:09:56] <cradek> you can't just change it at the last layer because they will be not synchronized with the upper layers
[12:10:38] <almost_bold> +cradek: I know I was here also, but honestly we did not understood it well enough. Sad but true.
[12:11:22] <almost_bold> Can you inform a GCode that we can look at that would have a similar functionality?
[12:11:25] <cradek> yeah unfortunately it's complex, and you need to understand more of the code, and you cannot do it in a day or two
[12:11:44] <cradek> linuxcnc doesn't have any gcodes that do this kind of thing yet
[12:12:13] <cradek> jepler found the code other controls use for it, but I don't recall what it was
[12:12:44] <archivist> I can think of a use with A,B as well :)
[12:12:45] <cradek> jepler said smid says M14
[12:12:55] <cradek> (found in scrollback)
[12:13:30] <almost_bold> 1 day or 2 already are already gone. I know that no code does this in linuxcnc, but for me to try something I must, base my search in linuxcnc for a code where I can understand the workflow.
[12:14:21] <cradek> we have this syncing behavior when you turn machine off - command follows feedback (for all axes)
[12:14:32] <almost_bold> already tested it
[12:14:42] <cradek> I think that is the closest code you will find to what you need
[12:14:42] <almost_bold> just a moment
[12:15:02] <almost_bold> I already tested this:
[12:15:04] <cradek> I'm not saying that's your solution, I'm saying that's some of the code you could study
[12:15:16] <almost_bold> it is very simple indeed:
[12:15:54] <almost_bold> case EMCMOT_MOTION_DISABLED:
[12:15:54] <almost_bold> /* set position commands to match feedbacks, this avoids
[12:15:54] <almost_bold> disturbances and/or following errors when enabling */
[12:15:54] <almost_bold> emcmotStatus->carte_pos_cmd = emcmotStatus->carte_pos_fb;
[12:15:54] <almost_bold> for (joint_num = 0; joint_num < num_joints; joint_num++) {
[12:15:54] <almost_bold> /* point to joint struct */
[12:15:55] <almost_bold> joint = &joints[joint_num];
[12:15:55] <almost_bold> /* save old command */
[12:15:56] <almost_bold> joint->pos_cmd = joint->pos_fb;
[12:15:56] <almost_bold> /* set joint velocity to zero */
[12:15:57] <almost_bold> joint->vel_cmd = 0.0;
[12:15:57] <almost_bold> }
[12:17:08] <cradek> yes but also need to check how the canon and interpreter levels resync at machine-on
[12:18:15] <almost_bold> yes that is probably our error. we are changing things on a deeper layer than we shoud?
[12:19:16] <cradek> well you have to change all layers so they know about this new ability
[12:20:35] <almost_bold> Someone wants to pass some days in Portugal? Now we have about 35 ºC and we live near beaches:
https://www.google.pt/#q=praias+algarve&gws_rd=cr
[12:29:10] <jepler> reference for m14/m15:
https://books.google.com/books?id=tviCBgAAQBAJ&pg=PA150&lpg=PA150&dq=smid+m14+spindle&source=bl&ots=MxJQdGPIAo&sig=zcgxgLJJF3XJA_IxYw_DyQkTlwI&hl=en&sa=X&ved=0ahUKEwjxg-mRx9_OAhXIXhoKHVUiD3QQ6AEIKjAD#v=onepage&q=smid%20m14%20spindle&f=false
[12:30:19] <jepler> Looks like in this sample, M103 is turning on the "live tool spindle" while the lathe spindle is in C-axis mode
[12:31:04] <jepler> other reference (also smid) for m14/m15:
https://books.google.com/books?id=w7-jBgAAQBAJ&pg=PA460&lpg=PA460&dq=smid+m14+spindle&source=bl&ots=VZC29-2ynE&sig=meikySjzXBAlNgRrUYJ9zX50OqQ&hl=en&sa=X&ved=0ahUKEwjxg-mRx9_OAhXIXhoKHVUiD3QQ6AEIJDAB#v=onepage&q=smid%20m14%20spindle&f=false
[12:32:21] <jepler> afk
[12:33:23] <almost_bold> well I know how they work (had machines before with C axis) and I already can work with this exact machine in C mode (in linuxcnc)
[12:33:53] <almost_bold> the "only problem" is switching from spindle to C axis.... just this problem
[12:34:05] <almost_bold> where the following error trips
[12:34:47] <almost_bold> this is way that we were trying to force pos_cmd = pos_fb, during spindle operation
[12:34:56] <almost_bold> so that in the time of changing back to C axis
[12:35:08] <almost_bold> it does not have ferror
[12:35:20] <almost_bold> All is working except this
[12:37:35] <almost_bold> Ah, and important: we can actually do this, force "pos_cmd = pos_fb", but when going back again to spindle mode the commanded position changes to the last commanded position that we were in C axis.
[12:37:50] <almost_bold> Hard to explain.
[12:37:57] <seb_kuzminsky> that makes sense, i think
[12:38:28] <seb_kuzminsky> the part of linuxcnc that commands axis positions (Interp, inside of Task) doesn't know that C changed while it was a spindle, so when it becomes an axis again, the old command is applied again
[12:39:01] <seb_kuzminsky> that's the thing cradek was saying earlier, that this change you want to make requires that all the layers are synchronized in their beliefs about where the axis is
[12:42:13] <almost_bold> unfortunately that situation is above our coding capability
[12:45:25] <seb_kuzminsky> almost_bold: :-(
[12:45:36] <seb_kuzminsky> linuxcnc is a big, big, hairy software project
[12:47:53] <archivist> with hairy coders :)
[12:50:32] <almost_bold> that's why this is too much for me
[12:52:41] <almost_bold> ok, honestly I thank you all for your suggestions and Filipe (emcPT) will take it from here. He also have more hair than me. Cheers
[12:53:28] <seb_kuzminsky> good luck
[13:58:00] <kirk_wallace> I have been working on G76 for the Tormach lathe manual. We added tapered threading but the manual wasn't updated. In updating the manual a few issues came up. Here is a link to what I have so far, plus highlighted comments:
http://wallacecompany.com/t_tmp/G76_doc/G76-2a.html . I think I am getting it sorted out, but any comments are welcome.
[13:58:39] <kirk_wallace> Hmm Smid seems to like exit tapers:
http://wallacecompany.com/t_tmp/G76_doc/Screenshot_smid_g76.png
[13:59:45] <jepler> cool, these guys made their goal
https://www.crowdsupply.com/eoma68/micro-desktop I wonder if they'll deliver the product
[14:00:34] <jepler> (arm computer in pcmcia-sized "standard" form factor, which you can insert in miniature desktop and laptop adapters)
[14:00:48] <seb_kuzminsky> so like a phone?
[14:01:23] <jepler> no display though
[14:02:04] <jepler> 68-pin header on one end (that's the EOMA68 "standard") and whatever is not too tall or wide to fit in the height available on the other -- the initial cards have hdmi, usb micro b, and SD card I think,
[14:02:29] <jepler> pi2-ish in computing power I think (allwinner A20) but with 2GB RAM and 8GB NAND flash
[14:05:32] <seb_kuzminsky> funny that they offer Devuan instead of Debian
[14:05:41] <jepler> they have a bunch of choices actually
[14:06:10] <jepler> parabola(?), debian, devuan, fedora
[17:52:45] <seb_kuzminsky> guess who "won
[17:53:07] <seb_kuzminsky> who "won" the CNC cookbook controller popularity poll this year:
http://blog.cnccookbook.com/2016/08/26/outstanding-satisfaction-loved-cnc-controls-2016/
[17:54:04] <cradek> huh
