Advanced Search

Hello Zelo,I had a similar problem, and sometimes I even manage to encounter it again. I think the issue might be related to the slider settings for the speed scale in LinuxCNC.The error you mentioned is caused by an incorrect position for joint0. This phenomenon can likely be triggered in various ways. One possible cause might be the low value set for the parameterin thefile. Try increasing this value.During my experiments, I also encountered such situations, but they were caused by using a configuration file meant for the basic version and then mistakenly running LinuxCNC with a configuration describing a machine operating in DMA mode. I think this issue is independent of whether you have DM556T drivers connected, as these are drivers that do not operate in a feedback loop with LinuxCNC+EC500. Therefore, during testing, you can focus more on configuration settings rather than hardware.It’s possible that after these 2 days, you started LinuxCNC with the correctfile matching the configuration you uploaded to the EC500, namely.

I have a problem with my hand wheel xhc-whb04b (wired version) on my machine.
A few weeks ago I have installed LinuxCNC 2.9.3(iso) on my mill pc, but I missed to configure my hand wheel. Yesterday I wanted to do so.
So I made a new HAL-file from the 2.8 documentation , insert the lines for halui inside the ini-file, added the .rules-file and reload it with udevadm.

When I start LinuxCNC and the hand wheel is ON, it works.
When LinuxCNC is running and I switch the hand wheel ON for the first, it works too.
But If I switch it OFF and ON again, when Lcnc is running, I can see totally wrong position values and after a few seconds it switches to Lost RF. I need to restart LinuxCNC to get the hand wheel back to work.

I try this on a virtual machine with Lcnc 2.9.1, 2.9.2 and 2.9.3 with the same problem.
On my milling pc is also my old 2.8.4(deb10) installation and there is no problem with it.

When I start "/usr/bin/xhc-whb04b-6 -p" on 2.8.4 I can switch it OFF and ON and the program is still running. If I do it on 2.9.x it stops working after the first turn off.
I also copied the file from 2.8.4 to 2.9.x with the same result.

Does anyone else have this problem?

i had forgottten about that, but no it is very outdated. sorry i forgot to get conner's repo will look now.

rmii dont work with lolin s2 mini, have message :A fatal error occurred: This chip is ESP32-S2 not ESP32. Wrong --chip argument?have anyone succes with esp32 s2 or s3 board?

@RDA,

Here you see a xyz + a move. Using a blend radius in the corner.

At Github i found something from you. Does it works with the actual version ? 

regards 

EDIT:Weird, tried to make it working for 2 days. Today i shutdown everything and few hours later without any config change it started working...

I was able to successfully flash remora to ec500 rt1052 with nvmpg and display is working correctly.
Using basic config from repo I'm able to move axes but when I try DMA config i get "Error on joint X" error.

What i did:
- used linuxcnc 2.9.3
- flashed controller with 3.1.3 firmware - display works
- installed both components from: github.com/scottalford75/Remora-RT1052-c.../LinuxCNC/components
- uploaded DMA config to controller (did that multiple times across restarts): github.com/scottalford75/Remora-RT1052-c...ec500-rt1052-DMA.txt with below settings for each axis (I'm using DM556T drivers)
```
        "Step Length":        3, # (at least 2.5us pulse width)
        "Step Space":        3, # (at least 2.5us pulse width)
        "Dir Setup":        5,  # (at least 5us before step drive)
        "Dir Hold":        5 # (also tried without that but no difference in behaviour)
```
- used example config from repo for DMA from: github.com/scottalford75/Remora-RT1052-c...CNC/remora-ec500-DMA

Now when i start axis UI and try to move any axis i get error:
```
joint 0 following error
emc/task/taskintf.cc 976: Error on joint 0, command number 107
```

I have 4 stepper drivers wired, 3 axes configured and problem occurs on each of xyz.

Any ideas what may cause this behaviour?

 

Benb wrote:

The hardwired diagram shows two normally open contacts in series  KM1 AND KM2 indicating that the Estop is active. The rest of the circuit is similar to what you had in mind. Please do not add a screen (UI) estop or reset buttons; make it a habit to only use the external hardwired estop and reset push buttons otherwise you defeat the use of a safety system. The hal block diagram I use it to generate the hal file but it might help you understand what the hal net file does.

 

  

I like your diagrams, what do you use to make them?

I'm not 100% sure the above diagram will work exactly like this with my setup, however your input sparked an idea to solve my "circular dependency" problem between the software and hardware latches: I need to use a "oneshot"-component to connect the two latches instead of connecting them directly(and thereby creating the problematic circular dependency). Sounds obvious now, not sure why i didn't see that option the other day. So thanks for the input, i think i have a viable way to solve this now!

rodw post=317388 userid=20660
iocontrol.0.user-request-enable can be used as an estop reset signal (eg in place of S6). A short pulse is sent on this output for this purpose. I chose to just stick with the external reset button and connect to iocontrol.0.emc-enable-in, I used a relay on your S6 circuit to do this

Thanks! I couldn't wrap my head around this at first, but i think i got the gist of it now. I'll try to implement this short pulse and post the solution here for future reference.

​​​​​​​Thanks!

In setting up my console, I set the following parameters to position the lug of the switch in the correct orientation, according to the number of positions the switch will be using, when the positions are centered about 12 o'clock. The only variable is the number of switch functions.

The lug is physically at the six o'clock position, relative to switch position 1. When in QIV, the view is from the operator, looking at the switch from the top; when in QIII, the view is from the rear of the panel.

I normally use Solidworks, but I figured folks that wouldn't know how to do this are more likely to be using Fusion, so here you go:

Anything apart from XYZ will revert to a single line lookahead. This can, and most likely will, create very jerky movement.

It would be great if this would be improve, as I would say its far from optimal.

grossm5000 wrote:

Ok guys, I've got it mapped out as shown in the attached picture. The common wires are in fact the grey and white wires. My plan is to supply 24VDC to the common wires and then plug in the other wires as inputs on the 7i77 board. 
 

I wish I'd found this earlier - it would have saved me a lot of back and forth! There appear to be exactly two posts on this forum that feature real binary switches - mine and yours - and I find it confusing that this industrial standard is absent from the fund of knowledge here.

Either way, we came to the same conclusion independently, and I'm curious how you implemented the switches in LinuxCNC. I just switched to this software and I don't know what I don't know.

snowgoer540 wrote:

Grotius wrote:

Hi,

I have version V2.10.1 here.
The tp.c file is last modified :17-05-2024 19:40


 

For the record, I’m not talking about their new changes for the 1500MX which has their “high speed machining”. I’m talking about >3 axis look ahead with blended motion.

Not sure what they changed back in May, could be as simple as a comment or a bug fix. Either way, their 3+ axis look ahead has been part of “PathPilot”’for quite some time. That’s what I was referring to as being tested in the wild for years.




 

Hmmm. I am talking about the jerk control feature myself. I thought that came in specifically with the 1500.

For me there's not much point in a new TP without jerk control. The look ahead and path smoothing works fine enough that the next stumbling block is jerk, and not path smoothing.