Advanced Search

Yes, I'm pretty sure we can delete that one.

Ah, I see what you mean, the A value being 180° because the tool coordinate frame is pointing away from the flange. You are rotating the tool frame in the kinematics. Ok that shouldn't be the problem then.
Can you post a screenshot of the situation when you start the example program?

I went a bit deeper into this rabbit hole and picked up some used panels. Still waiting for them to arrive. Not Haas though - I missed out on that deal.

But it turns out, sometimes (often?) these panels are a mix of both a raw matrix output and USB or PS/2. Like the Syntec and their clones as shown here . In the latter case, the "CNC'ish" buttons are all just a matrix but the keypad/numpad come out as a standard PS/2 protocol. 

viewsat wrote:

I use ./bin/rio-flow riocore/configs/TangNano9K/config.json
The automatically generated ini and HAL files cannot output a 1kHz PWM spindle signal. Do I need to edit the HAL and ini files myself to output the spindle PWM signal?
 

What does your setup look like?
Which interface are you using, and where do you want the PWM output to be?

To use the spindle in LinuxCNC, you still need to configure it in the “Signals” tab.

  dty/net = spindle.0.speed-out
  enable/net = spindle.0.on



@all WARNING: Serial/USB does work, but it's really just for testing;
I wouldn't use it in a production environment.

I was away for a bit but thanks so much Mass.

Thanks for elaborating on why you went with encoders. Syncing with display sliders and resetting to 100% on a press of the knob sounds like good ideas.

I think I read somewhere that the sliders can be made to move with the rotary switches and then if you go to make an adjustment on the slider, it overrides the physical knob. And then when you turn the knob again, that takes over and the slider follows along.
But I can imagine going back to the knob might make some abrupt speed changes. So, having full sync all the time and thus encoders sounds preferable unless one is OK with never/rarely using the sliders.

In the meantime, I picked up three used panels for a steal. They are not SKs but the arduino project and your info will still come in very handy when it's time for me to try to hook them up. If I give up on those, they were so cheap, I can grab an SK4 and make it happen faster thanks to this thread:)

babinda01 wrote:

Hi Guys. I have used RIOcore on a Tang Nano 9k (TangBOB board) a couple of times. I am now wanting to try out Ethercat. I was wondering what my options are for doing this. I want to use a RP5 with the Tang connected via an SPI connection to the GPIO pins on the RP5. My first question is where do I connect my Ethercat Drives? from the RP5 or from the Wiznet module connected to the Tang. I would dearly love it if all my configurations for Ethercat can be done within RIOcore.

Cheers
Andrew
 

Hi Andrew,
EtherCAT must be connected directly to the RPi5. Rio runs independently of it; it can only adopt part of the configuration (and even then, only to a limited extent).

 

I got my hands on a used 4th axis but need to put in a new servo which is fine. I have a Delta B3 750w servo and drive with absolute, multi turn encoders on the way (used, too). 
The machine will have Mesa cards but given that the 4th axis supposedly has no homing sensor (still waiting for it to arrive), I was hoping to be able to home it to the absolute encoder of the servo.
Would it be possible and not too difficult to use the RS485 from the drive into the host PC (with a USB adapter) to do the homing? AI seems to think so but I don't know how well versed it actually is in LCNC. It did however say that latency shouldn't really be an issue given that this is homing routine done at the start and not something that happens during actual machining. 

If this is not doable or takes a lot of trickery, I will try to put in a small hall effect sensor and home to that + Z-pulse. But would be nice if I didn't need to do that. 

I feel a spam coming on...

TCP is where the magic (and head-scratching) happens in 5-axis machining. Whether you're using G43.4 style dynamic TCP or delegating coordinate transformations to your CAM post-processor, having LinuxCNC handle real-time spatial transformations keeps feed rates consistent across multi-axis arcs. Super helpful thread for anyone moving beyond standard 3-axis setups!"

Logthor wrote:

Cool, I will probably go with the parallel port in the meantime, then. I should have enough I/O with the parallel port to control my x, y, and z axes and my spindle, right? I'm just looking for a yes or no regarding the timing issue and whether it would be a problem or not in making that part (assuming I have 15000-20000 nanoseconds jitter).

Yes, I have started a video series on a parallel port control board from scratch. This is the first of 3

This is new for me as I've only used Mesa and Ethercat before.
Spindle is working fine with 0-10v control, There is enough inputs for estop, probe, home switches and outputs for coolant, mist etc so it will be complete.

The plan is to redo the spindle to use RS485 Modus and eventually migrate it to Mesa and even Ethercat. This is more of a training video than for a specific machine although I'll eventually build one for it.

 

I use ./bin/rio-flow riocore/configs/TangNano9K/config.json
The automatically generated ini and HAL files cannot output a 1kHz PWM spindle signal. Do I need to edit the HAL and ini files myself to output the spindle PWM signal?

Cool, I will probably go with the parallel port in the meantime, then. I should have enough I/O with the parallel port to control my x, y, and z axes and my spindle, right? I'm just looking for a yes or no regarding the timing issue and whether it would be a problem or not in making that part (assuming I have 15000-20000 nanoseconds jitter).

They just posted this, but 15000$ seems a bit far out, although the only thing close to it is BaxEDM and i do not know what that goes for, so might still be OK price.
I wonder if they implemented the "back off on short" functionality, i know someone on youtube did some 10 years ago.

And they use the open source nature to to their benefit with "no cloud, private, etc" , nice.

I've found having a spindle encoder really nice. Specifically, the spindle-stall detection. It's definitely saved breaking some tools. Depending on how the spindle is set up, you may be able to get that without an encoder (and it may be a non-issue anyway if you use your machine within its limits and don't have a dubiously-tuned servo as the spindle motor).

TheTinkeringMechanic1 wrote:

After posting that image of the g code I believe I see it now. The % symbol is on line 5. So that would explain everything being off set considering the line is starting at 1...
I knew it had to have been something silly.

Update: That was it.... 

Thank you for reporting back.