Advanced Search

Joco wrote:

For awareness:

The scurve planner has some behaviour changes around:
motion.feed-hold
motion.adaptove-feed

Under the standard planner per documentation the effects of these pins can be enable or disabled through the use of M53 and M52 respectively.  These M codes are not supported under scurve.  The effects of these pins are always active.

If this departure from current behaviour is material and of concern then we would be interested to understand what the "real world" down sides are to this implementation.

Thanks - James.

 

I've never used a feed-hold disable function; I suspect it's a legacy feature intended for machines run by operators who are not 'allowed' to really manipulate the controls.  Or the programmer sees a feature to be cut where feed-hold would lead to issues (drill/tool rubbing and work-hardening the part) and turns off feed hold for that program segment.

Neither have I used adaptive-feed, but I could imagine a situation where the programmer or operator would like to turn it off/on.  Perhaps using block-skip in the program for segments (roughing, maybe?) where adaptive feed is appropriate but not fully proven out.

xenon-alien wrote:

I'm appreciate your help!
I will try to figure it out.
But an understandable manual would be better (to not bother other people with beginner stuff). I hope Andy will do it sometime.
 

The maual is pretty comprehensive, but I agree it could use some help.

Problem for most beginners - and anyone confused on a particular topic - is that the MAN pages don't have a lot of context.  It's very difficult to understand what a MAN page is all about with no underlying basis for understanding the terminology or jargon.

And it's likely just as hard for the author of a component MAN page to know what context or examples to include so a beginner-level audience can understand the component or subject without too much difficulty.

Final problem is that 'beginner-level' is a vague term.  I've noticed that people who frequent the forum have a wide range of experience; some have programming skills, others have mechanical experience, some have electrical, and so forth.

Writing a help manual targeted at the lowest common denominator means including tons of info many people will find annoyingly superfluous.  The author(s) just don't know what the audience already knows... hence the forum questions.

I was able to figure it out in the hal. I just usedto invert all my inputs. My estop is even working too!

tommylight wrote:

It MUST have 2 switches, one for each side, this can do gantry squaring every time the machine is homed.

Okay this makes sense ill fire one and get it wired in. How would the hal differ below is my best attempt. 

Those are magnetic encoders. No optics at all. Are there any part numbers for the encoders?

For awareness:

The scurve planner has some behaviour changes around:
motion.feed-hold
motion.adaptove-feed

Under the standard planner per documentation the effects of these pins can be enable or disabled through the use of M53 and M52 respectively.  These M codes are not supported under scurve.  The effects of these pins are always active.

If this departure from current behaviour is material and of concern then we would be interested to understand what the "real world" down sides are to this implementation.

Thanks - James.
 

  When trying to run a macro located in the "macros" folder, we get an error "File not open"  
  At the same time, in the MDI mode, the button of this macro and the image, which is located in the same folder, appear.
The file will work only if it is placed in the root of the folder configuration or the root folder nc-files.
This happens only on some configurations.
For example, I had a configuration with an ATC carousel, everything worked. I converted this same configuration to a ladder - and it stopped working. 
It is more convenient if the macros are in a separate folder.

Grotius you're a madlad

I'm pretty sure you can just send this to a university and they'll send you back a math degree diploma

I've been away from the game for quite a while as I was finishing school myself, but I'll put this to work in the near future

thanks so much! I only bought two of the eventual 5 axis, which are Lichuan OL3-E57H open loop stepper drivers. I have an xml file from the manufacturer and they are supposed to be CIA402 compliant, but I don't yet know how to set this up.

Even while the carousel component is running, it is impossible to stop the process (in MDI mode, there is a cross in the lower right corner), only the program can be completely turned off. Even if an error occurs, for example, the tool search time has expired.

O_o

o_O

Okay good deal, glad you got it working.

If you list your equipment that you are using, one of us will help you with the XML.  I will try to check back at some point to make sure someone or myself helps you get it going.  I apologize if I don't get back really soon, just overloaded with work and have very little free time.

Thanks,
Robert

@Julian,

Hal blend speed is a special feature, Mr. Lcvette requested this feature a while ago.
Blend speed can be used to tune a machine to it's inertia limits.

The blend is the fillet (rounding) between 2 trimmed (shortened) gcode lines (segments). Given the G64 P[..] value.
The blend speed is a factor value "0-1".
The blend speed is used to tell the planner how to behave at the blends, focussing on blend speed.
Curvature is the ammount off roundness of a arc or circle. It is related to the radius.
Based on curvature -> radius, the blend speed is calculated by mathematics.

-> hal_blend_speed
minimal value : 0.0
maximal value : 1.0

Example :
hal_blend_speed 0.0 = use blend speed based on curvature only. (safest way of running the machine, lowest output speed)
hal_blend_speed 0.5 = use 50% speed based on curvature, use 50% speed based on gcode feed.
hal_blend_speed 1.0 = use gcode feed only. (can become risky, machine may run beyond inertia limits, highest output speed)

On youtube there is a video, where you can see the difference at runtime on a real cnc machine.
Later on in the video the hal_blend_speed is set to 1.0 at time 5:51
video link

Then you can for example tune your machine to a hal_blend_speed : 0.85
This then you can edit in the source code and recompile. Then it becomes a startup value.
fill in blend speed here.

Wait where is my clean up towel.

Warning: PC pron ahead !

Hi,

To understand the function call flow from rtapi to components i made a compact example a while ago.
This is a universal approach, same as lcnc uses:
function loader

Normally you can just create new thread. This one uses a json file to load threads, shared mem, components.
new thread

Ok, so it would be reasonable to assume that if I moved the rtapi call from motmod/tpmod to somewhere else I should not expect weird side effects since this is all done through the fairly standard RTAPI API.
The dlopen call from rtapi is straight into the component motmod or tpmod lib's function.
You can not move it around, but you can create logic to manipulate or change rtapi calls.

One other question I have is, why is there a limit on the # of threads created and the order they are created in? Is this again a convenience/limitation made to simplify things or more of a deliberate design trade-off?
I did not know this but in terminal : ulimit -a
Is the limit of posix threads for users. Admins may do more.