Messages

11

SmoothStepper USB / Re: Smooth Stepper "External EStop Requested" after "Tool Path Display" Motion !

« on: June 18, 2011, 02:13:26 PM »

Hi guys,

Jeff hit the nail on the head.  It didn't occur to me for a while but then I remembered that the watchdog timer is probably causing the problem.  Here is how you can figure it out.  Watch the blinking red LED when you manipulate the toolpath.  If it stops blinking, that means Mach is no longer communicating with the SmoothStepper.  Each time the red LED blinks, the plugin is sending a message and the board is responding.  I believe Mach4 will solve this problem since it will give lower priority to the graphics and more priority to the communications with the external device.  Increasing the Watchdog Timeout setting in the SmoothStepper's Config is about all you can do for now, besides letting go of the toolpath more often.  I think it depends a lot upon the graphics because it doesn't do it on my computer.

Greg

12

General Mach Discussion / Re: MACH 3 Major E-STOP ISSUE:

« on: March 09, 2011, 03:02:01 AM »

It sure sounds like the SmoothStepper's USB communications are getting clobbered, but from the videos it looked like the red LED was still flashing.  What happens if you do it with the data monitoring window open?  Which version of plugin are you running?

Thanks,

Greg

13

General Mach Discussion / Re: MACH 3 Major E-STOP ISSUE:

« on: March 09, 2011, 02:47:38 AM »

That is very strange.  What does the status is the SmoothStepper's Data Monitoring dialog say?  There is both a checkbox for EStop and also the raw data from the inputs.  Is Port 1 Pin 10 checked or not?  According to the data you presented, it should not be checked when the button is released.

Thanks,

Greg

14

General Mach Discussion / Re: MACH 3 Major E-STOP ISSUE:

« on: March 09, 2011, 01:55:14 AM »

Hi diyengineer,

You should really reconsider your EStop.  At a minimum, EStop should kill power to your servo drives.  You shouldn't trust anything short of a mechanical switch to stop movement.  Killing power to the motor drives is the only safe thing to do.

With that said, I noticed in one of the videos that showed the SmoothStepper's data monitoring screen, that the EStop flag was checked.  This says that the SmoothStepper thinks the EStop is asserted.  In Ports & Pins you showed it as being Active High, which means the EStop needs to be at +5V in order for it to be in EStop.  I would go straight to the source and use your volt meter to measure the voltage on pin 10 of port 1 before and after.  You must release the EStop in order for it to get out of EStop.  Otherwise Mach will stay in that state.  If the EStop button is released and the voltage on that pin stays stuck high, then there is a problem with the breakout board.  This is an input on the SmoothStepper, so it is unlikely it is causing it to stay stuck.

Greg

15

SmoothStepper USB / Re: SmoothStepper Modbus RPM DRO conflict

« on: January 11, 2011, 11:53:14 PM »

Hi Peter,

I understand the frustration when threads go off topic.  From my point of view, the thread wasn't just about the index not being connected because I needed to take a holistic approach to the problem if I was going to effectively solve it.  If I came up with a solution that didn't consider the case of threading, I might see another thread pop up tomorrow about threading not working.  I thought the thread was finished, and Jeff was capping it off with information that I thought was relative enough to the topic.  We can disagree about how relative it is, but I think it was relative enough.

Now we're definitely getting off topic!  

Cheers,

Greg

16

SmoothStepper USB / Re: SmoothStepper Modbus RPM DRO conflict

« on: January 11, 2011, 07:19:10 PM »

Hi Peter,

Jeff was just "expanding on this thought" and pointing out that if you want to thread, the Index must go through the SmoothStepper.  He wasn't trying to contradict anything, just pointing out an important fact.

The Smooth Stepper plugin should know that no index sensor has been configured and therefore not write to the spindle RPM variable.

Your statement is similar in nature, because it represents one aspect of the complete logic.  It is true that the SmoothStepper should not write to the spindle RPM variable if the Index is not enabled.  But in addition, if the assigned port is not a SmoothStepper port, then that is another case where the SmoothStepper should not update the spindle RPM variable.  I think those are the only two cases where the SmoothStepper should not update the spindle RPM variable.  If anyone knows of any others, please let me know.

Thanks,

Greg

17

SmoothStepper USB / Re: SmoothStepper Modbus RPM DRO conflict

« on: January 11, 2011, 02:10:15 AM »

I'm sorry Peter.  Should be OK now.

Greg

18

SmoothStepper USB / Re: SmoothStepper Modbus RPM DRO conflict

« on: January 10, 2011, 11:55:23 PM »

One minor point.  The Index can be on port 1, 2, or 3.

Greg

19

SmoothStepper USB / Re: SmoothStepper Modbus RPM DRO conflict

« on: January 10, 2011, 11:34:40 PM »

Thank you Peter and Peter.  Sorry this took a while.  I think it is really simpler than what you describe.  I think the only thing that matters is whether or not the Index is enabled, and whether it is on a SmoothStepper port or not.  If it isn't enabled on a SmoothStepper input, there isn't much I can do about it.  Thank you for outlining your thoughts so nicely like you did.  Please let me know if you think I overlooked something.  If the user does not use the Step/Dir or PWM outputs for the spindle, they still might have the Index defined so that they can measure spindle RPM.

I have compiled a new plugin that includes this option.  Here is the direct download link:

http://warp9td.com/files/SmoothStepper_v17a.zip

Thanks,
Greg

20

SmoothStepper USB / Re: SmoothStepper Modbus RPM DRO conflict

« on: December 15, 2010, 10:59:52 PM »

I think that Mach decides where to send spindle commands to.  If the spindle is assigned to port 0, then Mach should issue a ModBus command and the SS shouldn't hear about it.  Spindle Speed is assigned to a Mach variable in the SS plugin.  It uses the Spindle Index input to calculate the speed.  I think the SmoothStepper plugin code is the problem.  I'm surprised nobody else has reported this as a problem.  The SS code doesn't look to see if the spindle is assigned to a valid SS port when it writes to the Mach variable that displays the spindle speed.  I can make some changes to fix that.  Additionally, I am thinking that I should relax the requirement of port and pin assignments.  If it is not a valid port, then pop open the dialog that alerts the user.  I will need to have a check box that says "Don't ask me again", since those people with Modbus controllers will not want to be bothered by this every time Mach starts or port and pin reassignment info is sent to the board.

I see a bit of a dilemma with respect to which device controls the display of the spindle RPM.  For threading, it is imperative that the SS use the Index input (or in the future, the encoder A or B phase) directly on the SS.  It needs that information immediately available, and it reports the spindle speed to Mach, and Mach calculates the trajectory based on the reported speed.  Maybe it is possible to allow ModBus to update the spindle speed, but the SS will still need the Index input defined.  In this case there would need to be an extra control that decided which device updates the Mach variable.  That of course will be going away with Rev 4 of Mach.  The plugin won't have access to those variables any more, so maybe it won't be a problem then.  Mach will be using functions to transfer data back and forth, so it will be up to Mach to decide whether or not to use the data.  Much better than multiple plugins each stomping on the same global variables. For now, if the Index input is define, the SS will update Mach's variable.

I'll look at it tomorrow and see if I can make a new plugin with that fix in it.

Greg