Advanced Search

Could you post the G-code that is giving the error? Not necessarily the the entire G-code program. Especially if the program is large. Just a snippet that includes at least a few lines before the error, and a few lines after, so we might be able to test and reproduce the error. It's a little hard to see and understand what is going on just from your image.

The error joint2 limit error is not caused by your hal or INI settings.
It results as it tells you, because the movement in line 11 will exceed the soft limits.

As you mentioned, that will happen more often with long tools, as your code will use a length compensation for tools.
If the preview window is updated, you will see that limit violation too.

Try the following:
- Change to the longest tool.
- set Z axis to cero on the top face of your workpiece.

Now it should work. 
 

I did a complete re-install and made sure I selected the right board starting config, and now everything works as normal. I must have accidentally started with a tangBOB starting config instead of the TangNano9K, or something along those lines, so as I was re-installing linux/checking hardware I brought the problem along with the original JSON file every time I tried fault finding.

If nothing else I can serve as a bad example !
Cheers.
Russell.

160i is what i recall from the naming on the console, it was made in 2012, again i think, as i do not care much about such info when tasked with making such things work.
I will update info whenever i get a chance, as the stress is gone so now i might also do a less shaky video.
I said "i might" ...

that things sick, i wish i worked around something that epic and complicated, what fanuc is that thing running? when was it even made?

I'm attempting to build a multicolor titanium anodizing machine it has one axis of movement and a variable power supply the goal is to be able to define the power supply as the x-axis and the movement as the z. That will keep everything synchronized and allow me to program my color gradients but it also means that given the same f value the actual z axis feed rate will vary depending on the rate i change the power supply, im looking for a way around this. Im not sure whats best, can i just remap a mcode and run a python script that can keep them synced up and use single axis z movements? how hard would it be to edit the base level linuxcnc code to change the way it calculates the axis feed rates? That would be ideal and im willing to figure it out but i dont even know where to start with that, any advise would be greatly appreciated. 

The machine did stop the cutting job. We stopped the job because the torch didn’t fire. No idea why. Last time it worked without issues. LinuxCNC froze when my friend tried jogging the machine back to the starting point of the cut. No idea why it did that. Maybe pressing the keyboard continuously caused the freeze !
We do have a physical emergency stop wired to the setup so no worries there.
Now the issue is the machine just jolts when enabled and we get a joint 0 error. I even upgraded to the last version of linuxcnc but I get the same behaviour. Machine Enable > jolt with error !

Yeah, it seems you can't do that with the standard cia402 component.
It only support csp mode(1) and possibly csv(0), and what I read your device is working in asynchronous velocity mode(2) and that's not supported at least fully.
It's the controlword, obviously, that starts and stops the motor.
Normally the cia402 component has full control over the controlword and that must be now manipulated by setting on and off bit 4-6 (7F vs 0F) for start stop
There is the option to modify the cia402 component, but maybe "easier" to manipulate the controlword
between cia402 component and lcec.

Break the connection between cia402 and lcec controlword and insert something like
if op-enabled (controlword bit 0-3 set) and start pin (new pin)
  set controlword bit 4-6 true
else
  set controlword bit 4-6 false
with hal logic. The resulting controlword connects to lcec.

In addition to that, don't connect any of the cia402 commanded or feedback pins, do the speed setting and speed feedback outside the cia402 component. Basically, the cia402 component will bring the device to op-enabled, that's all. You set the op-mode and all speed settings directly to lcec.

 

A classic case of RTFM... Thanks Lcvette, I'll check it out tonight

Yes, you can use spare encoder inputs as MPG interfaces.

Note that with high resolution encoders, you lose the 1 count
per detent feature of 100 PPR MPGs.

Can i use the 7i95T Mesa boards 4,5,6th axis encoder inputs as MPGs?

Most probably yes.

Hello all... I am looking at retrofitting a Prototrak DPMV5 mill, its supposed to have electronic handwheels as well as full CNC mode.
I am making new electronic handwheels- instead of using the 100ppr units you can get cheap, i want to use a 1024ppr encoder and custom made wheels. Bringing me to the main question: Can i use the 7i95T Mesa boards 4,5,6th axis encoder inputs as MPGs? Arguably with real good encoder counts? Or am i limited to using the 8 inputs as MPGs for the normal 100ppr units?
The machine I have is electrically stripped, so imagination is the limitation (okay maybe wallet too).

ps: I have retrofit a VMC and converted a manual lathe to CNC using 360ppr encoders on the handwheels to make a similar manual/cnc mode. Sometimes it misses counts when i spin fast using a 7i76e MPG inputs.

Thanks!
 

This is not a full fix, but it reduced the issue from 50% to less than 10% of the probes.  I added in a 'Queue-Buster' if statement.  see the bold/italic lines below.  If anyone has any better solutions I'd love to hear them, but for now I think I can move forward with my machine. #5070 will be set to 1 maybe one time out of 50.  If anyone knows the source file where the 'Queue is not empty after probing' is coming from I'd be glad to look myself.  I found the listed file in my last post, but it seems to be a general error reporting function and not the source of the error.

o<tool_probe> sub
O999 if [#<_task> EQ 0]
O999     return
O999 endif
G17 G20 G49 G90
G0 G53 X35.52 Y13.415
G0 G53 Z-8.5
G91 G38.3 Z-4 F10
O998 if [#5063 GT 1.0]
    G91 G0 Z0.1
O998 else
    G91 G0 Z0.11
O998 endif
(DEBUG, Z#5063 #5070)
G90 G0 G53 Z-8.5
o<tool_probe> endsub
M2

Been tasked with making this monstrosity work as it was delivered, mounted, installed, but never tested nor shown it actually works. It is a Mazak with Fanuc controls, has probably over 30 axis in total, pneumatic, Oxygen, 4KW of laser power, nearly 40 meters long, works with 15 meter long tubes, etc, etc.
Took me nearly a whole day to figure out everything due to no prior experience with such machines, and having 3 separate PC's controlling it did not help, but a bit of fiddling and by the evening it was fully working, loading files included.
Next day was spent with the CAM portion and teaching a young employee (actually one of the owners sons) about the procedures of transferring files, copying them into the Fanuc memory, opening and running them, homing everything (3 separate homing procedures), measuring the material (done automatically), adjusting feeds and speeds, adjusting laser power and air assist, changing nozzles, recovering from failed cuts, resetting sensors used for area safety, etc, etc.