Advanced Search

I would expect the tool table to work for this application. I have suggested it before and nobody has come back to say that it was a terrible idea.

Is it possible that you have accidentally switched to a different "workspace"?

G71 and friends exist mainly as an alternative to CAM, to make hand-coding easier.
I don't know of any CAM system that generates G71 (which isn't to say that there aren't any). But I don't think much would be gained from doing so.

I tried riocore with a Tang nano 9k last year, when I first read about it. I loved the idea and I think you have done a fantastic job so far.
So a big thank you, although I have not done anything productive with LinunxCNC and riocore yet, mainly because I already have some Mesa cards that I use in my machines and not the time that I would like to have to start experimenting with a fun project with riocore. I love the idea that for simple projects I could potentially use riocore with a cheap FPGA board though, so hopefully I'll do this in the near future!

I have a project in mind right now though, that would ideally use a microcontroller for sending commands to the FPGA for driving two motors and I would like to know if I could potentially connect an ESP32-S3 or ESP32-P4 that I already have. I'm only familiar with Arduino framework so far and I tried to dive further in ESP-IDF in the past but that was more hard for my current experience. Do you think it would be possible and fairly simple to communicate an ESP32 board with the Tang nano over SPI, like your LinuxCNC driver does?

Kostas

The standard LinuxCNC disk image does not, as far as I know, disable WiFi. You should be able to get the time in the usual way.

Okay, we will try to confirm that it is our servopack.

Does anybody have experience with position control mode on the SGDH-10AE or another Yaskawa sigma II series servopack?

FYI, when I ran my full configuration the vfd would work correctly at startup but would fail after several commands. Sometimes after homing, sometimes after MDI commands, but seemed to lock up and stop sending commands to the VFD. No errors reported in hm2_modbus and did not recover after set/clr the modbus reset.

I looked at git repo and saw several updates after the 2.9.8 tag. I have not noticed any lockups since installing and running the RIP master. I do get a few dialog errors about PDU too small while running but I don't lose control of VFD.

Hello everyone,

As most of you know, Stepperonline A6 servos have 17-bit multiturn encoders. 
Encoder cables with battery boxes are also available for these servos. The cables are supplied with batteries.
When these cables are used, the servos become multi-turn absolute value encoders and the reference run is no longer necessary.

Here is a step-by-step guide on how to set up the servos after installing the cables.

1. Switch on the servo.
2. Set parameter C00.07 > 2 (linear mode, absolute position).
3. The servo displays error ER20.8.
4. Set parameter F31.10 > 4.
5. Switch the servo off and on again.
6. Perform a reference run.
7. The .hal and .ini files must be adjusted.

I recommend commenting out the relevant sections.

HAL:
remove or  recommend commenting from all joints: 
 => cia-statusword
and remove or  recommend commenting section #CIA Custom Homing

INI:
remove or  recommend commenting
[EMCMOT]
# HOMEMOD=cia402_homecomp

[JOINT]
HOME_ABSOLUTE_ENCODER     = 2
HOME             = 0
HOME_OFFSET         = 0 
HOME_SEQUENCE         = 0
HOME_SEARCH_VEL     = 0 
HOME_LATCH_VEL         = 0
HOME_IGNORE_LIMITS    = YES

# only for homing
#HOME                 = 0
#HOME_OFFSET             = 0.0
#HOME_SEQUENCE             = 2                 
#HOME_SEARCH_VEL        = 1
#HOME_LATCH_VEL            = 1
#HOME_IGNORE_LIMITS        = YES
#CIA402_HOMING_ENABLED         = 1
#CIA402_HOMING_METHOD        = 4
#CIA402_HOMING_SEARCH_VELOCITY    = 300000
#CIA402_HOMING_LATCH_VELOCITY    = 30000
#CIA402_HOMING_ACCELERATION    = 131072

Now, all you have to do is press the home button after switching on the machine, and all axes are immediately referenced.

That's it.

 

 

JT

 


Note that to get 0 PWM at startup or watchdog bite you may need to

1. Chose the output polarity that is 0 at startup ( I think this is the - pin )

2. Invert the PWM output in HAL
 

Yeah, it appears libusb_context is defined in libusbi.h, which is not part of the normal "distribution package". I missed that. There are several compilation defines/options for libusb, which makes a bit more difficult to understand exactly what is happening. But I do think that your libusb_set_log_cb() should have done the trick (unless for some of those compile time options).

It was a little bit strange from the start that it succeeded to print that debug message and only afterwards seemed to hang (which we now know was a segault). I wonder if there could be something wrong with the handling of variadic (=any number of) arguments, which messes up the stack and in the end gives the segfault.

I had a second look at the issue you created a couple of years ago. And yeah, already there you identified libusb as a problem. I don't think really put much thought into that the first time I read it.

Hannes have made a pull request which is waiting to be accepted into LinuxCNC. Andypugh bought a similar pendant and will test the code once he receives the pendant. I guess if he is happy the PR will be accepted. Maybe in 1-2 weeks, is my guess.

I don't think it's possible to switch to manual mode while a program is running or paused. Which is what Hannes version checks for. I presume that if the program is running/paused, it needs to be stopped prior to making the mode change. But I have not verified that. If you are not having a program running/paused, then jogging should change to manual mode.

If you have an external device that does the A-D,
and it  can output a frequency proportional
to analog voltage, you can read that frequency
directly with an encoder input (set to counter mode
instead of quadrature mode)

Yes, the PNP connection is correct for a 7I76E field output (With appropriate series resistor)

Note the the default operational mode for Step drive enable inputs is disabled when powered
(which is the exact opposite of the desired operation from a safety standpoint)

Unless you can reverse this (so they are enabled when the enable input is powered)
You may need to add an external relay.

If the motor keeps turning without step pulses, this is a root of the problem
and there's nothing on the LinuxCNC/7I95 side that can fix this.

It really sounds like the drive is in velocity mode.

What should I be looking at with the oscilloscope? I have checked that our signal looks like it is supposed to and when I press the continuous jog, it stops about when I release the continuous jog and the motor keeps spinning.

We went through a back and forth with Yaskawa before this to confirm it is in position mode, because that was our first thought. What I don't really understand is how the 7i95 board knows it is supposed to generate position based step generation when we are sending it velocity commands?