Advanced Search

Taking an educated guess, it could be a permission issue, using the link you provided and removing the filename gets a directory listing in a browser, 403 is there when trying to download, other files are accessible.
Hopefully Andy will become aware of this, one option might be to access either the mailing lists, I'm banned due to comments on the origins of Code of Conducts and implementor, or GitHub.

Why have you hacked the motor feedback and enable?

net xpos-cmd <= joint.0.motor-pos-cmd => remora.SP.0 joint.0.motor-pos-fb
# net j0pos-fb <= remora.joint.0.pos-fb => joint.0.motor-pos-fb
# net j0enable <= joint.0.amp-enable-out => remora.joint.0.enable

Your hal file has no endstops configured...?

cmorley wrote:

The 'def get_handlers(halcomp,builder,useropts):' function has the wrong indent.It should have no indent just like the class definition.Ok, I simplified my test code (see attached .py) and started to see some light at the end of the tunnel. However, When I click on either the on-min-clicked or on-max-clicked buttons, the logging shows that the call to get_factor() is written before the line identifying the handler being called (set attached .log).  Further, only the first line of each handler or function is being printed, but no errors are being tossed that I can find.Any ideas?

I ended up with a set of StepperOnline DM860Tv3 drivers for x, y, z. They seem to be working fine and the machine moves in all 3 axes now.

When trying to install the update for 2.9.5 on a Raspberry Pi, I receive a security error when attempting to fetch The error is:

Forbidden
You don't have permission to access this resource.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Yes this should be raised as an issue, GitHub might be the best place.
I concur with your statements regarding relative vs absolute moves.

Please disregard the comments in the previous post as they appear to have been made by an idiot.

I have a hard time seeing that this could be intentional design as randomly changing the behavior of MDI commands without any hint at all to the user can be very dangerous.

An MDI move command in G90 can yield very different results compared to one in G91.

@scotta it would be really helpful if you can post sample config files. Or if I need to completely erase skr3 and reflash using stm32cube programmer?

I didn't ever say thanks for your reply PCW so a belated thank you! Yes, the 7i96s. The above is working with the VFD set in 'pull-up' logic which is great. I still need to connect the VFD digital outputs (ST1 & STR) to the 7i96 inputs to signal when the motor is running at the commanded speed and when there is a fault. I also initially forgot to configure the PWM signal in pncconf initially.

A few more questions:

1) My VFD programming has the following setup:

• Minimum frequency of the motor: 100Hz (6000 RPM)
• Maximum frequency of the motor: 300Hz (18000 RPM)
  
  
  In pncconf I set the max spindle speed to 18000 which I can see in the machine.ini file:

  [SPINDLE_0]
  ...
  MAX_OUTPUT = 18000.0
  OUTPUT_SCALE = 36000
  OUTPUT_MIN_LIMIT = 0
  OUTPUT_MAX_LIMIT = 18000

   
  However, in the same file, I see the qtdragon display section with the following:
  

  [DISPLAY]
  DISPLAY = qtvcp qtdragon
  ...
  MAX_SPINDLE_0_OVERRIDE = 1.000000
  MIN_SPINDLE_0_OVERRIDE = 0.500000
  DEFAULT_SPINDLE_0_SPEED = 500
  MIN_SPINDLE_0_SPEED = 100
  MAX_SPINDLE_0_SPEED = 2500
  ...

  
  When I select FWD/REV in the gui, I am seeing the spindle spin in the correct direction and the VFD is correctly driving at 100Hz (i.e. the minimum safe speed for the spindle set in the VFD programming). Do I need to manually change DEFAULT_SPINDLE_0_SPEED, MIN_SPINDLE_0_SPEED, MIN_SPINDLE_0_SPEED? in the QtDragon [DISPLAY] settings in my .ini file or should pncconf be sorting this out?

Thanks Andy! I will try to play around and will come back.

Either way will work, there is no technical advantage of using 2 external
inverters.

Pullups/pulldowns on the 7I92T don't really matter for this specific signal
since they are overdriven by the Schmitt trigger

(the pullup/pulldown mode may matter for other signals)
 

A voltmeter will do, you just need to jog the MPG
so you can measure the high and low states.

I guess I am going to need an oscilloscope?

I would check the swing of the A,B MPG signals, relative to ground.
The input threshold is about 2.5V with ~20% hysteresis so needs a good
say 4V swing to work reliably.

forum.linuxcnc.org/30-cnc-machines/31792...rofit?start=20#85718