Advanced Search

At the moment, whether or not "sserial_port_0=0xxxxxxx" is added to the hm2_eth line, all 7i42TA pins behave as GPIO - they can be set/cleared in halshow.

This is expected behaviour: if a sserial device is not found on a particular channel, its I/O pins revert to GPIO

I would be grateful if you could send the firmware for that card including: 6x analogue servo, 6x encoder, 2x pktuart and 2x sserial modules, for 7i80HD-25, 7i48, 7i52 combination.

I'll try and get to this sometime today or tomorrow.

OK this worked and we got rid of the type error, if i start i now i get a attribute error: object has no attribute 'PREFS_' , i hope you dont get frustraded with me its all very new for me. I really appreciate your work with me. And it means a lot.

please build your panel as a main window instead of a dialog

No idea how this happend i will post and check it this time

The ui files are 0 kb for some reason

I'm not expert too, I've just been experimenting with AI and looking at the halscope, trying to wrap my head around things in general, it helps to just chat about these things, even just to make sure I'm not persuing a weird irrational tangent, and I'm actually making sense not just to myself lol. YangYang has the math down, he is the main arbitror, nothing goes to master without his stamp of approval, and he checks on what the AI comes up with, and so far nothing really sticks, only what he write himself works best. I've found something with the arcs, I want him to take a look, and I think we maybe possibly be able to do similar tricks with Béziers, but I don't want to keep your hopes up, I think it is possible that, the fact that Béziers change curvature, may not fit with the current tp lokahead/blending architecture, but maybe... maybe I am wrong.

Yeah for sure these are the files, the error code is already above.

Actually, when I think about the proposed integration of 9axis blending, it might indeed be wiser to stick to the circular arc.


In any case, at the end of the day it will always be better to have something that works than something that might be even better but never gets done. So thank you guys for working on this.

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