Advanced Search

 

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? 

yes, at the moment i play with 1Mbit over RS422-Drivers and the exsisting uart plugin, i allready test 2.5Mbit without problems between two FPGA's.
The protocol is the same generated like between FPGA and PC plus checksum for serial.
Since only the bare minimum is transferred, the delays are extremely small.

the Firmware generator supports RP2040 (incl. waveshare zero) and ESP32 MCU's
based on Arduino toolchain, but you can use the interface stuff (pure c) for other controllers and own drivers that rio can not generate as a template.

I used RS422 so that simple cables (network/RJ45) can be used to bridge longer distances without any problems. This means, for example, that the step/dir generators can be attached directly to the motor if they have built-in drivers.

I am currently testing an MPG based on pico, which is also connected via RS422 (including power supply).

Hi, I'm currently running linuxcnc through a systemd service with linuxcncrsh as the fronted.
Usually it starts up fine and all the functionality is working as expected, but when the system first boots up and the service gets executed i get this from linuxcnc:

As I understand it the trajectory planner tpmod doesn't get loaded properly. What is unusual is that linuxcnc keeps running and seems functional but the robot exhibits very strange motion behavior. When i then check hal for loaded components tpmod is loaded and ready?
When i restart the service after this first boot it runs perfectly fine, it's only when i power cycle the machine that this error pops up.
Any ideas about what the cause might be?
Thank you!

Hello,I am currently retrofitting a Biesse Rover 336 with LinuxCNC.The machine is controlled with a Mesa 7i77, and I am using EtherCAT modules distributed throughout the machine for the I/O.Originally the machine had a Control Techniques Unidrive VFD, but I was unable to change the required parameters, so I replaced it with a Danfoss VFD, which is now working well.At this point the machine is mostly operational:

• Homing works
• XYZ motion works
• Spindle runs correctly
• The toolchanger sequence is mostly prepared

So I am approaching the final stages of the retrofit.I am using Probe Basic as the interface.Machine configuration

• Toolchanger: 7 tools
• Vertical drills: ~25
• Horizontal drill (X axis): 1
• Horizontal drills (Y axis): 3

My current plan is:

• Tools 1–7 → spindle toolchanger
• Tools 101–130 → drill bank (fixed tools)

Questions about tool offsetsFor the drill bank I need to determine the XYZ offsets relative to the main spindle.I am unsure what the best way to handle this is.Options I am considering:

1. Store the offsets in the tool table (like normal tools)
2. Apply the offsets inside the M6 tool change routine, since these drills are fixed and it may reduce the chance of mistakes.

Do tool table offsets work correctly for horizontal drills, or is there a better recommended approach?Fusion 360 questionI also created a test piece in Fusion 360 to test the horizontal drills.However I get the following error:
 Error: Function 'positionABC' can only be used with multi-axis machine configurations.
Error at line: 2040
Error in operation: 'Drill2'I suspect this may be related to how I defined the horizontal drilling operation.Is there a recommended way to program horizontal drilling for drill banks in Fusion when targeting LinuxCNC?Any advice from people who have implemented drill banks or horizontal drills on router-style machines would be very helpful.Thanks!

What comms layer are you thinking for data between the FPGA and MCU? You mention rs422, so I assume high bandwith serial over differential driver? I was going to use SPI with included SYNC signal for timing integrity but serial will use two FPGA pins and a differential driver instead of my scheme that will use 5 pins. I love the Tang Nano, cheap, and great toolchain. If I could keep using it then life would be good, pin count is it's worst enemy!
Cheers.
Russell.

Oh very nice, one of those micro's look like the waveshare 2040zero and the other a pi pico? I have been playing around with using the pico, probably a 2350b with 48GPIO as an expansion port via SPI and using a SYNC pin from the nano to take snapshots at 1KHz intervals to keep readings accurate for encoder positions. The Pico's are awesome for this kind of work, serious cheap hardware. I also plan to use Tang to SPI to pico bus topology for expansion boards, mainly IO, if I want step/direction I will try RioSub, most of my machines are closed loop to the controller so only pwm/dir to Hbridges, but I have friends that want to use step/dir with commercial drives. I will test this on my own machines, let me know if you want anything specific for me to test.
Cheers.
Russell.

Hi,
I would like to connect the ena+ and ena- inputs of my Leadshine DM856 to a Mesa 7i76e. If you look at the attachments... which circuit should I use? I would say PNP... but is that correct?

You wrote:
“It can be seen that 1C12h should be set to 1600h and 1C13h should be set to 1A00h to activate the variable PDO mapping.”
Set this if possible. Lcec will take care of the rest when linuxcnc starts up and set the correct addresses on the servo. This is the same for Stepperonline servos. 
You will then see the correct assignment when linuxcnc is running. If not,  you may have to set the assignment in the servos manually.

 

I tried that already, there is no access to log_handler.
struct libusb_context is not defined, only the pointer to it.
I tried with 
in process(), but no change.
There was a new message when restarting the connection from 
and that didn't crash even if it uses the same underlying log_v function.
I leave it like that.

The problem has been the assert statement. But I tested to remove that some two years ago
(the github issue) and failed in the same way it does now. But in general the assert is what
people experience, I understood.

I'll test Hannes' version next.

Edit: Tested, it avoids the mode switching altogether. I think that is perfectly fine.
I don't expect to switch to Man mode and jog when I'm running a program. Could happen
by mistake even. If I feel a need to switch to Man I'll designate a button for that.
I have a vague memory I did that on the previous generation xhc.

Is it in a shape to go into linuxcnc repo? I think it should end up there.