Advanced Search

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.

Hi,

You are completely right. I took a step back and realized it makes much more sense to update my GUI to use a -100 to +100 slider so I can take advantage of the hardware direction.

So YES, please link the DIR pin to the PWM direction (your standard way).

Thank you for catching that and pointing me in the right direction!

I need to control the feed override of the linear stage. Range is -10 volt to +10 volt. I want to keep 0 volt for 100 % feed override while -10 for 0 % override and +10 for 200 feed override. Resolution can be as good as possible, for now I can go with 0.001 Volt. This can be achieved if there is analog voltage input pin available in Mesa board. In my case I don't have analog pin in mesa 7i95 board. So, I planned to use 1 free encoder pin out of 6 in board. I also need to program in my Arduino or LabVIEW such that I can send fix number of pwm pulse to get the correct encoder count and map it successfully to +/- 10 Volt. Once it mapped correctly i want to bind the pulse count pin with feed override pin.

Please suggest how to do it the,  I'm looking for more than one approach to do the same and implement the simplest one. Because Mesa 7i87  board is not available in stock, so I'm looking for any similar board that can do my job.

Thanks.

Good morning,
thank you very much for your response. It's a good option, I'll keep it in mind.

Thank you very much.

But I cannot define PDO mapping in the drive itself. The control device i.e. the EtherCAT master should write the PDO mapping on startup.

I found a few ways of defining the SDO in drive from LinuxCNC - sdoconfig and initcmds.

What do you mean by adjusting the servo?

So you want the DIR pin to be GPIO rather than PWM direction?

( The PWM direction pin is controlled by the sign of the PWM value )

thanks for the thoughts. ill be hopefully getting this ordered up in a few weeks. should be fun

Complete success with the lathe modbus communications. Much faster and works fantastic with the automatic gear detection. 

forum.linuxcnc.org/10-advanced-configura...tion-updated-for-vfd

There is no "E-stop in" in your hal file, so LinuxCNC has no way of knowing if the button is pressed or not.

I used the TangentAudio source code to build a driver for the Commander SK VFD, This worked, but when I implemented automatic gear detection, I found the updates were too slow. I was able to replace the user mode driver with hm2_modbus.

If anyone is still using a user mode driver and has a mesa card, you should consider replacing it with hm2_modbus and the CommanderSK.mbccs I posted in:

forum.linuxcnc.org/10-advanced-configura...dated-for-vfd#343921

 

Ok, everything has settled, homes and I have a working machine but ESTOP external button versus software - the external button kills the mx3660 but does not trip in LinuxCNC

Played a little, read some, and am giving the following thinking someone may have the fancy answer.

ESTOP external is NC switch setup, has a NO side not using.

Machine enabled Halshow results:

• ESTOP External OFF:     pin.003.in  RED
• ESTOP External ON:     pin.003.in  RED
•          pin.003.out              no change
  
  Software ESTOP:
  • OFF         pin.003.in                 RED
  • OFF         pin.003.in_not          YELLOW
  • OFF         pin.003.out              YELLOW
  • ON         pin.003.in                   RED
  • OFF         pin.003.in_not          YELLOW
  • OFF         pin.003.out               RED
    
    Understand from reading that the output/input somehow can be linked to false or other pin - tried, I get config errors, no load.
    
    Again, not a deal breaker, but when the external ESTOP is triggered such as during a home, the motors stop but when I raise the button the machine continues - like it paused not ESTOPPED. That's a little disconcerting.
    
    Attaching HAL file.
    
     

    File Attachment:

    File Name: 010.hal
    File Size:10 KB

I have been running my mill and lathe without accurate RPM control/calibration. Recently, I stumbled upon forum.linuxcnc.org/47-hal-examples/27071...r-detection?start=20

I broke down my implementation of this idea into three files:

• LatheSpindle.hal - General spindle control and automatic gear detection scaling.
• cmdr_wrapper.hal - Implements hm2_modbus for CommanderSK VFD.
• Spindle_postgui.hal - Scaling for use with gmoccapy.Using hm2_modbus provides much faster communications and better gear detection during accel/decel than the user mode driver I previously used. 
  
  
  
   
  
  The gear detection magic occurs by using the ratio of the spindle frequency to the vfd motor frequency. If you have a number of gears or belts, each combination will have a distinct ratio. You use this to populate the x values of the lincurve. For the y values you use the scaling necessary to scale the spindle command frequency to the required vfd motor frequency. It's quite easy to collect this information.
  
  
  

I used a wrapper around the VFD commands so I could share code with my mill that uses a GS11 VFD.



I'm very happy with how this turned out! 

No, you just adjust the servo and the ethercat master and your ethercat.xml take care of the rest. 
 

Thank you very much for everything you do.

I just had a quick look, but might go a bit deeper at another time.

The ctx/context appears to be the libusb_context struct. I guess you could just do after libusb_init in usb.cc:
github.com/LinuxCNC/linuxcnc/blob/master...whb04b-6/usb.cc#L629
But this probably isn't the best workaround in general.

I guess most of the problems in the past has been because of the assert statement in setupAsyncTransfer? Or did the pendant never reconnect for you in the past? When I was testing and just unplugged the dongle and plugged it back in, it usually didn't fail in the setupAsyncTransfer function, so the assert statement didn't prevent reconnection.

You might also be interested in testing the changes made by Hannes:
github.com/hdiethelm/linuxcnc-fork/tree/xhc-whb04b-6-fix-v2
I believe you need to do a "git checkout xhc-whb04b-6-fix-v2" after git clone in case you want to test that. With regards to the disconnects, his solution is more elegant than decreasing loops, because it avoids trying to change mode altogether when it's clear it would fail anyway.