Advanced Search

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.
 

Might look at the step pulse train with an oscilloscope.

Also is it possible the servo drive is not set to position mode?
 

Okay, is there a way to verify that it is an electrical/wiring issue?

OK so that may still be an electrical/wiring  issue

(if the DRO does not move but the motors move)



 

DRO updates to the inputed position about a second after .1 inches is inputted and the motor continues after that. The DRO doesn't update again until another input is entered. 

Does the DRO show movement when jogging should  stop?
 

No, I don't know how to change log level even.

Fresh git clone of libusb1.0, configure and make.
Fresh git clone of linuxcnc.
It has been the same behavior/problem with the libusb-1.0 via apt in debian.
This is a problem since a long time, years.
And this N100 PC is relatively new, latest debian and don't have any history.
Except the linuxcnc config, it is the same.
Hard to find something that sticks out.

I provoked the xhc a bit. Easily crashes with wrong loop setting. But it now recovers after three seconds.
This is a situation I can live with. It would have been better with no crash. Until then, this is fine.

The modification I made was in libusb1.0.
What I see is that if one setthe problem will not appear, the callback function pointed to by context->log_handler will not be called.
Do you know if this can be done in the xhc component code?
It would be good to use std libusb1.0 libs.
 

All the results have been done with the AXIS GUI inputs.

Does jogging via the GUI work?
 

I made this tool manager for the second generation QtDragon, but there's no reason it couldn't be a standalone application. Currently, you can assign tools to groups, such as Drills, spiral upcuts, whatever. Each tool can be assigned material specific cutting parameters and the running time for each tool is tracked according to how long it was in the spindle while a program was running. The linuxcnc tool table is the source of truth and tools can only be added or removed by editing the tool table. The database can be exported to csv or html.  I'm not a machinist, so this was only a guess on my part about what kind of data to record. Looking for suggestions on features, changes, etc. Regards.
Jim