Trigger Dig. Out depending on the covered distance

TopperH
Offline
New Member

17 Dec 2014 22:45 #54096 by TopperH

Trigger Dig. Out depending on the covered distance was created by TopperH

Hello everybody!

I'm building some kind of 3D-Printer with LinuxCNC and a Mesa 6i25 + 7i76 / 7i78 combination. Due to the help of this forum, the basics machine is working as expected.

But I have a question regarding an advanced function.
(I'm quite new to LinuxCNC and this forum, so please excuse and move the thread if it is not that advanced and there might be a better sub-forum.

)

My problem ist, that I want to trigger one or maybe two of the 7i76s digital outputs depending on the traveled distance of the toolhead. So for example set DO_0 to HIGH after 10mm and back to LOW after another 2mm and so on...
( I don't have a coolant system, so I could use these outputs too, if this makes the whole task easier?

)

I hope you could help me, thanks a lot in advance!

Please Log in or Create an account to join the conversation.

bkt
Offline
Platinum Member

18 Dec 2014 03:30 #54102 by bkt

Replied by bkt on topic Trigger Dig. Out depending on the covered distance

If your problem is how to connect DO-0 of mesa card..... I can't help you..... you need mesa expert..... if your problem is how to use motion.digital-out see motion.9 ....linuxcnc.org/docs/html/man/man9/motion.9.html ... M63_65 ..... custom component and probe is other two solution.

Please Log in or Create an account to join the conversation.

ArcEye
Offline
Junior Member

18 Dec 2014 17:30 #54118 by ArcEye

Replied by ArcEye on topic Trigger Dig. Out depending on the covered distance

My problem ist, that I want to trigger one or maybe two of the 7i76s digital outputs depending on the traveled distance of the toolhead. So for example set DO_0 to HIGH after 10mm and back to LOW after another 2mm and so on...

The problem is not triggering an output per se, rather how it is done.

Need to know what you are intending doing with these outputs and why?
By toolhead are you talking about table travel in relation to the tool, or actual tool movement ie the quill / Z axis?

regards

Please Log in or Create an account to join the conversation.

TopperH
Offline
New Member

18 Dec 2014 20:01 #54121 by TopperH

Replied by TopperH on topic Trigger Dig. Out depending on the covered distance

Hi!
And thanks for your answers and interest.
The connection itself will not be the problem. As ArcEye said it's the question of how it ist done.

So answering your questions, the table is moving below the tool. But does this really make a difference?
I want to use the output to control for example a magnetic valve to apply some additives in a regular pattern along the path.

By travelled distance I mean the lengt oh the path. For example if I go from x0y0 to x20y10, the travelled distance is approx. 22.36.

Please Log in or Create an account to join the conversation.

ArcEye
Offline
Junior Member

18 Dec 2014 20:17 #54122 by ArcEye

Replied by ArcEye on topic Trigger Dig. Out depending on the covered distance

So answering your questions, the table is moving below the tool. But does this really make a difference?

It certainly makes a difference in trying to understand what you are trying to do.

I want to use the output to control for example a magnetic valve to apply some additives in a regular pattern along the path.

If the additive something to aid cutting and needs to be deposited at 10mm intervals, would it not be better to slowly deposit it continually throughout the cut?

If it is for something else, my first thought is that if this additive needs precise regular placement the method is likely to be wrong
By the time the fact that 10mm had been reached registered, went from logic signal to electromechanical actuation, the distance would have overrun by a variable factor dependent upon velocity and acceleration.

A filter which breaks up all X and Y moves into 10mm moves followed by a M1XX code to deposit whatever is a possibility, but still not sure what the purpose is

regards

Please Log in or Create an account to join the conversation.

TopperH
Offline
New Member

18 Dec 2014 20:54 - 18 Dec 2014 21:02 #54125 by TopperH

Replied by TopperH on topic Trigger Dig. Out depending on the covered distance

Ok, to give you an overview, it's a research project for my university and the machine is going to be an automatic carbon fibre placement machine. So some kind of 3D printer, nothing to cut or mill. It should be used to evaluate the best/easiest possibilities to fix the placed roving in its position, before the completely finished part is infiltrated with resin afterwards.

So the additive could be some sort of glue, coming through the mentioned valve, but could also be heat or something else. I personally don't know it yet.

Also the 2 and 10mm were just the first simple numbers that popped into my head as I was writing the text.

could also be 1 and 42.37mm or continuous deposition or whatever else turns out to be the most effective.

So I tried to keep my question as simple as possible and stuck to the initial problem of turning the output on and off in a regular pattern.
I thought about dividing the path into smaller steps in a pre-processor, before writing the gcode. Maybe 1mm or less and than turning it on and off by M62/M63 commands after the desired amounts of steps. To give an adequate resolution in curved parts of the geometry I think 10mm would be to coarse. Is this the filter you're suggesting? Or is there a better way by a M1xx code started once at the beginning, counting the passed steps in a parallel loop an controlling the output? And if yes: How?

Or is the filter you're talking about somthing that lies above the gcode, not limited to the loaded geometry points?

Thank you very much!

Last edit: 18 Dec 2014 21:02 by TopperH.

Please Log in or Create an account to join the conversation.

ArcEye
Offline
Junior Member

18 Dec 2014 21:12 #54126 by ArcEye

Replied by ArcEye on topic Trigger Dig. Out depending on the covered distance

I thought about dividing the path into smaller steps in a pre-processor, before writing the gcode. Maybe 1mm or less. Is this the filter you're suggesting?

That is what I was thinking of, how easy it is to achieve in practice would depend upon the sort of code you use and what produces it.
Arcs would present a different problem of their own, working out degrees of movement and converting that to actual distance over the line of the arc at a given radius.

The problem with trying to obtain a figure of how far you had traveled within a larger move, is the interpreter does not concern itself with that.
It orders a completed move and the tracking would be via the difference between current and commanded position from the axis.
As I outlined earlier, I fear this method would be inaccurate due to overrun, the smaller the distance between points and the higher the velocity, the harder it would be to achieve.

I am sure others will have ideas on this

regards

Please Log in or Create an account to join the conversation.

bernie_nor
Offline
New Member

21 Dec 2014 07:51 #54179 by bernie_nor

Replied by bernie_nor on topic Trigger Dig. Out depending on the covered distance

Hi!

I'm also new to LinuxCNC. I guess you have a way of cutting the fiber. Using some custom M code or flood on/off or similar. And I also assume the G-code will be generated using a software developed in this project. So you can tell the programmer to add these codes when needed. I.e. Move 5cm. Apply the custom glue-M-code. Move another 5cm and so on.

But you also need to feed the fiber at the right feedrate I guess.

Another approach might be to add an extra joint. And for this joint you make up the math for it tomove the absolute distance for the X/Y axis movement. And by setting it up to have Ie. 100 step pr mm you can then add logic on you glue feeder to output glue every n steps. This output could also drive your fiber feeding stepper.

Cool project! Keep us updated!

Cheers!
Bernie

Please Log in or Create an account to join the conversation.

PCW
Offline
Moderator

22 Dec 2014 01:12 #54192 by PCW

Replied by PCW on topic Trigger Dig. Out depending on the covered distance

If you are just dispensing something why not just integrate the scalar velocity pin
(say just add velocity to a bucket every servo thread period and dump the bucket+pulse your
output pin when the bucket is full)

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

29 Dec 2014 07:25 #54351 by andypugh

Replied by andypugh on topic Trigger Dig. Out depending on the covered distance

TopperH wrote:
My problem ist, that I want to trigger one or maybe two of the 7i76s digital outputs depending on the traveled distance of the toolhead

This sounds like a job for a custom HAL component, as I don't think anything in the existing components is _quite_ right.
"hypot" does part of the job, but not enough of it.
There is code for a laser engraver that does something like what you want, but it also does rather a lot more, so is probably not the way to go.

Here is a custom component that appears to work:

component dashline "A component to toggle a pin at a given distance along a path";
license "gpl";
author "andy pugh";

pin out bit out;
pin in float xpos "should be connected to the x axis position feedback";
pin in float ypos "should be connected to the y axis position feedback";
pin in float zpos "should be connected to the z axis position feedback";

pin in signed motion-type "enable/disable the component. Link to motion.motion-type";
pin in unsigned motion-mask = 6 "choose the move types where the component is active. 0x6 for straight feed and arc but not rapid";
pin in float length "the total length of each segment";
pin in float on-length "the on-time distance";

pin out float total-distance;

variable float oldx;
variable float oldy;
variable float oldz;

function _;

;;
 #include <rtapi_math.h>
FUNCTION(_){
    if ( (1 << motion_type) & motion_mask){
        total_distance += sqrt(pow(xpos - oldx, 2) + pow(ypos - oldy, 2) + pow(zpos - oldz, 2));
    }

    oldx = xpos;
    oldy = ypos;
    oldz = zpos;
    // no "fmod" in rtapi maths so the obvious way won't work
    if (total_distance > length){ 
        total_distance = 0;
    }
    if (total_distance < on_length){
        out = 1;
    } else {
        out = 0;
    }
}

It needs to be linked to the axis positions and the motion-type.
www.linuxcnc.org/docs/html/man/man9/motion.9.html
motion-mask is a bit-mask of the motion types. 6 is the default and probably the most appropriate for almost all uses.

The following user(s) said Thank You: TopperH

Please Log in or Create an account to join the conversation.

Time to create page: 0.206 seconds