Advanced Search

Mate if you read the README on the GitHub page you will find out what do with the bin & bit files.
You also need to read the section about updating the Linuxcnc driver.

It helps to read, understand and implement the instructions that the developer gives.
The developer recommends Linuxcnc 2.10 or a patched version of 2.9.2
It’s been a good 6 months since I was evaluating this project so I’m not too sure where Linuxcnc is up to regarding the patches.
If it was possible to get one of the Ethernet chips going with original Mesa source there would be the ability to remove the on board RAM and get access to many more pins for IO.

Hello everyone, I'm going straight to the point hehe, I have in my possession a Maxifet AF series 60 10/20 driver and the respective motor that drives it, this is a DC driver and apparently the motor is connected in speed mode since it has a tachometer. It is connected to the driver, I would like to recover this driver but I can't find any datasheet on the internet, I have been reading some threads here in the forum about DC drivers and something very common is the analog +/- 10V data interface that the driver housing says. If this is the case, first I would like some advice on which control cards to use. I was thinking of using a 7i33TA. I imagine that this can be used with any card with a 50-pin control connector. If someone could point out one, preferably Ethernet, I don't know if there is one. Mesa card, with at least an analog output +/- 10V, I know that 7i96 has an analog output, I'm not sure if it's -10V and I think it is designed for spindle control, this output could be used to control one axis since I only need one axis
Anyway, if anyone has any information about this driver that they can provide and a combination of board cards to control it, thank you in advance, I leave a photo of the driver and a brief diagram of the pins that are used in the machine where it is installed, greetings   

Probably something missing in the hal or ini file, so do a side by side comparison in a text editor.

Is it possible you have disabled the pwmgen in the hal file?

You can check all available hal pins/parameters/functions with:

halcmd loadrt hostmot2
halcmd loadrt hm2_eth board_ip=10.10.10.10
halcmd show all > all.txt

Then to clean up/unload the drivers:

halrun -U

 

There's nothing to complain about I don't think. This is nuclear proliferation treaty stuff. If your country is in NATO, EU or china, you are a bit stuffed. If you are in Canada, google "dual use" VFD and the relevant paragraphs will come up.

I am talking with lenze and they are very helpful. The gist is that they can sell me unlocked drives, but they will need to be pinned to the END buyer. So let's say you bought my machine, lenze will log YOUR details as the destination of the drive and supply the device on demand (I won't have stock on a shelf). I am unsure what happens if you then sold the machine used later on. Do you need to report that sale and the buyers data? Seems like you would need to, cause the whole point is to track WHERE this drive is to make sure its not being sent to Iran or the like in some round about way. Lenze also confirmed that generic PMSM motor drives are still restricted so that doesn't help me.

So in all likelihood, I will sell the 50000rpm (800hz drive from lenze) version of the machine to Canada and the US, and then for the sake of hassle, I will restrict everyone else's machines to 36000rpm with a stock 599hz lenze or delta drive and rewound spindle.

Thanks for laying this out. One question remains: what if linear scales come into the equation? Specifically ones that are connected to the servo drive and fed back to linuxcnc via ethercat.
I’d assume thatcher best approach would be to handle this feedback in the drive (again). However, what about gantry setups?

(Ich hoffe englisch ist okay für dich)
I guess the problem here is that the modbus data are usually 16 bit wide and so does mb2hal interprets them.
But as the Linuxcnc HAL don't have have s16 and u16 types, the types in the C-code are chosen to match the HAL types so s32 is used for integer, so it will never wrap.
A possible fix for mb2hal would be to use s16 and u16 internally and then cast them to s32 and u32. But then we need a new for pin for each function code...

But until this happens ... I don't really see a better way than using a custom component like Andy suggested.

OK, spindle weirdnesses dealt with.

What should I use as a PC?
I want a mix of being small and reliable, as well as being cheap and easy to deal with if it dies on the customer end. So probably not some all in one pc box.

I guess we need at least 2 ethernet ports if we choose ethercat.

Anyone got a recommendation for a reliable cheap mini itx board that will work well with ethercat or mesa?

fish, do you have any info on the legislation? since it directly related to me I would like to understand/ complain to my mp

rodw wrote:

The joint axes that were added in 2.8 require homing before jogging as your error says.
I just got into the habit of hitting home all after power up so its not onerous and generally not difficult to add the required switches.
 

Got it, interesting.
 In the machine and in the old configuration of this machine that I built now, before using two sensors to square, I had the habit of doing the homing with the inductive sensors on the axes.
 But as in the previous format I was able to move the axes before homming, I found it strange that I tried to do the same now and the error message appeared.
 I will do new tests as soon as possible, thank you for the information and help.

New variety.
Here I understand there are problems with the settings.

 

I am sure the hal_gpio driver was tested and working very early in the piece from earlier forum comments.
linuxcnc.org/docs/stable/html/drivers/hal_gpio.html
The gpiod library used here is meant to be a generic GPIO driver (I think at the kernel level) that is designed to be multi platform so its unsurprising it works on the Pi5

But this does not appear to help with SPI unless its supported by gpoid

The joint axes that were added in 2.8 require homing before jogging as your error says.
I just got into the habit of hitting home all after power up so its not onerous and generally not difficult to add the required switches.

There were 3 files in the archive with examples; I uploaded the bit file to the board. What to do with bin files?

rv901t_4out__3stepgen_2enc_1pwm.bin  
rv901t_4out__3stepgen_2enc_1pwm.bit  
rv901t_4out__3stepgen_2enc_1pwm_initial.bin

rodw wrote:

You need to Home all before attempting to jog
If you don't have home switches, you will need to add them for a gantry as they are mandatory.
 

So with this configuration I need to do homming to release movement, right? Before, in the standard configuration of 3 motors, I moved the machine before homing without any problems...