Advanced Search

PCW wrote:

You MUST set the 7I97 PWMgens offset mode to true or runaways are guaranteed.
 

Yep, that fixed everything! Thanks a million! 

For those who run into this in the future, I needed to add to each axis definition in the .hal:

Where "xx" = joint number. 

Now the machine is stable and jogging smooth and silently. Beauty. 

please post your ui and handler file and the exact error message please.

Ive integrated your handler File now into the Main handler. Problem is that the Error Code is exactly the Same as before.

Hello,

Just for fun i also created a Polygon program where you can change direction (G2/G3), position, number of point/rounds and the corner radius.

For what option is chosen, doesn't the user choose with P-parameter of G64, how much the controller can deviate from the programmed points? Also by option 1, and acute angles should there be a user option to tell what is acute.

(long time reader, trying to do something back to the community, keep up the good work!)

I guess my question was, can I do this:That way I can split my config into different files and not need to coordinate use of components centrally.

You cannot maintain velocity, follow the exact programmed path, AND have smooth jerk.

This is physically impossible. What I am saying is I would sacrifice velocity rather than programmed path on G2/G3 programmed arcs. At the moment if you run something with tangent arcs even with G61 the velocity is kept, this messes with jerk. G61 with jerk will have to slow down more.
For many line segments G64 Pxx it also slow down more, the more tight the tolerance, the smaller blending arcs the slower you have to move.
Béziers will give you better speed, because you can run them faster, but they are NOT arcs, meaning when you program a square for example, just 4 lines, you set G64 to 0.5 let's say, what kind of path error would you accept? A 0.5mm perfect radius which I have to slow down more to make smooth, or a squashed up Béziers which I can run faster?

I don't understand this focus on not changing toolpaths.
The important thing is that we can define how much we deviate from the exact path.
The less deviation we allow the more we have to slow down. 

Even with perfect g2 continuous path blending there is jerk limiting needed at the beginning and the end of the blended paths as well as for jogging. So it's really always going to be Option 1 plus ideally Option 2.

Béziers complicate things

Well, that is certainly true. MUCH easier working with circular arcs. I won't argue there

Slow down at curvature changes: reduce Vel so the centripetal acceleration change is manageable. (this defeats high-speed machining)

This is what I mean is feasible, not ideal, but what we are working with that moment.

YangYang I think tends toward Béziers and smooth High Speed, but this changes toolpath, I'd rather slow down when necessary to make things smooth, and stay on path, which is generally more important than High Speed in our line of work.
I think slowing down on arcs is simpler to implement, Béziers complicate things, and I think, we will still need to slow down or at least calculate the proper speed to execute and stitch in the blend smooth Béziers at, which could prove to be a headache in my opinion, even though the path is smooth doesn't mean you can run tangential speed jerk control and get rid of jerk spikes, I don't think it works like that, but I'd be glad to be proven wrong, but still you would not be following a programmed arc and I don't like that...

There are 3 clocks because there are 3 BISS channels in that configuration

in addition you mast set the DPLL timer so that the BISS read completes before the nominal read time
something like:

setp hm2_5i25.0.dpll.01.timer-us -200

The 7I74 only outputs 5V signals so no 10V signal is possible other than
perhaps overshoot on an unterminated line.

The outputs swing from ground to +5V, so If you measure between
outputs, you could read +5V or -5V depending on the output state.

 

I think he is right, I tend for option 1 as well, actually already have it work pretty well in my testing.
Option 2 which is what the big boys use, Siemens Fanuc etc. as far as we understand, requires a complete TP rewrite

Hi,

ist ja nicht mein Thread aber vielleicht als Vorschlag, weil wir ja doch einiges thematisiert haben:

Möglichkeiten höherer Logikspannungen (>5V) für Endstufen (7i96(s) und Parallelport)

Yes, you can "addf" the and2 functions separately. This isn't true for all HAL components, some have a single read and/or write thread for all instances.

But for and2 you could have:

It is possible to retrospectively add functions in a position other than the end, if you really need to:



This seems to be less well documented than one might wish. Possibly it doesn't work properly. I think that positive numbers are position from the start and negative position from the end.

github.com/LinuxCNC/linuxcnc/blob/master...cmd_commands.cc#L318

Unless the supplier has documentation we can only guess at how the board is set up and how it works.

You could try to use the manual for the _real_ 7i92 from here:
www.mesanet.com/pdf/parallel/7i92tman.pdf

But if there are differences, then you may be on your own.

The ultimate goal is to have both Option 1 and Option 2. Jerk limited velocity planning AND G2-continuous transition curves.

Option 2 is where jerk limiting goes to die in linuxcnc.

Not sure what makes you say that as one does not exclude the other they actually complement each other.

20k latency seems fairly decent. With a base period of 50,000 that should never over-run.