Advanced Search

Thank you for help. Everything works just fine. Xilinx was a bit tricky to download due to american regulations and policies. Somehow registration form doesn`t work correct. But finally I downloaded it today so this is first and last case.

Talking about original mesa cards, in my country it is almost impossible to get desired board on time. They simply out of stock. So I had to save 15$... I`m sorry.

Xilinx itself appeared an old nightmare for me to install. Heavy virtual machine, only Win7 32bit and 30-year old interface... I would not recommend customizing chineese boards after this experience.

P.S.: hope people who don`t help use Windows

Looking for a lathe encoder hal for for threading and rpm. the files I find say to use the index pin however its not an option for the el5101 

I assume that LinuxCNC and LabView are not running on the same PC?

Is this conventional LabView or LabView Realtime? (if that even still exists).
(As an irrelevant aside, until last year LabView RT was the only thing that I had actually been paid to program in)

Have you considered not using the NI card for linuxcnc control, but instead communicating with LinuxCNC using linuxcncrsh?
linuxcnc.org/docs/stable/html/man/man1/linuxcncrsh.1.html

It sounds like, for whatever reason, tpmod isn't reporting "hal_ready()"

Though it seems odd in that case that LinuxCNC continues to load.

github.com/LinuxCNC/linuxcnc/blob/2.9/src/emc/tp/tpmod.c#L34

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.