Machsupport Forum
Third party software and hardware support forums. => SmoothStepper USB => Topic started by: peterc on December 14, 2010, 04:00:33 AM
-
I have a Hitachi SJ200 VFD running Modbus installed on my system with a brain to convert/send RPM to the RPM DRO. Without SmoothStepper running I have no problems running the spindle at speed or with the read back.
When the SmoothStepper is run I can start and stop the spindle but the RPM shows a constant 0. I can monitor the brain and the correct RPM speed is being sent to the DRO.
When I start Mach3 with the SmoothStepper I get the following error:
Spindle-Axis Step Port= 0. Valid values are 1 and 2.
Spindle-Axis Direction Pin= 0. Valid values are 1, 2, 3, 4, 5, 6, 7, 8, 9, 14, 16, and 17
I tried switching Step and direction to unused pins on ports 1 and 2 without success. The Modbus will only run with Spindle enabled on Port 0.
I am using the basic 1024.set screen set.
Attached is my xml file
-
The SS plug-in tries to make sure that the Ports&Pins settings are sensible, I suspect that Greg never thought about using one with a spindle that is on ModBus such as this. Perhaps this is something he can change in the plug-in? Why does the ModBus plug-in require the spindle to be on Port 0?
-
The SS plug-in tries to make sure that the Ports&Pins settings are sensible, I suspect that Greg never thought about using one with a spindle that is on ModBus such as this. Perhaps this is something he can change in the plug-in? Why does the ModBus plug-in require the spindle to be on Port 0?
The wiki says Modbus uses Port 0: In Mach3, one uses Port number zero to refer to the Modbus device
I also read somewhere (maybe the Modbus forum) that this is how others have set up their tools.
I did try using outputs from Ports 1 and 2 and still could not get a read back in the RPM DRO.
Attached are the Spindle and Motor Output settings that work with Modbus.
-
I've not used a ModBus controlled spindle before, but I see a selection there in the Spindle Configuration page for a ModBus spindle. Is there a reason you are using a Brain rather than the built in functionality? Also, how do you have the spindle configured in the SmoothStepper configuration screen?
-
I've not used a ModBus controlled spindle before, but I see a selection there in the Spindle Configuration page for a ModBus spindle. Is there a reason you are using a Brain rather than the built in functionality? Also, how do you have the spindle configured in the SmoothStepper configuration screen?
The Spindle Configuration page Modbus spindle is for the MOD/IO board and not for a directly connected to serial port Modbus device. In the SmoothStepper configuration I have tried PWM and Step/Dir but I still get a constant 0 RPM in the DRO.
-
Have you tried setting the SS config to None/Relay?
-
Have you tried setting the SS config to None/Relay?
Jeff,
Actually I have the setting at None/Relay. I tried the other settings (PWM, Step/Dir) when I didn't get the correct RPM DRO reading.
-
OK. I sent Greg a note about this. He has been working on the plug-in recently so maybe it is something he can look into. Can you attach the brain that your using, perhaps a tweak can be made there to get it to work.
-
OK. I sent Greg a note about this. He has been working on the plug-in recently so maybe it is something he can look into. Can you attach the brain that your using, perhaps a tweak can be made there to get it to work.
Jeff,
Attached is the brain I use to read RPM in Hz. from the VFD. convert to RPM, send to RPM DRO.
-
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
-
Greg,
If the spindle is assigned to port 0, Mach3 doesn't automatically issue a Modbus command. The user needs to set up the Modbus configuration to get the Modbus command sent to the Modbus device. The user then needs to write a brain to store the returned value into the TrueSpindleRPM variable.
If someone wants to do threading, then yes, a index sensor into the SS is required and it can not go through Modbus due to the latencies in the Modbus protocol.
So, if the user needs to do threading, they need an index sensor to be fed into the SS, and the SS will also be able to calculate the spindle speed.
Therefore there should never be a legitimate reason to want to get the spindle speed via Modbus and at the same time use a spindle sensor into the SS (or parallel port) for threading.
Cheers,
Peter.
-
My temporary work around until this bug is fixed was to rename the RPM DRO to a user DRO. This does not work on some G code I run because the program will stop at any spindle speed changes because there is no speed read back.
I think this bug has a easy fix. Below are my ideas.
If the spindle is enabled on port 0 then assume a Modbus spindle is in use. Step and Direction both are port 0. Step Pin# and Direction Pin# can be 0 or any number.
If Modbus Spindle AND Index not Enabled Then do not process RPM functions (don't interrupt any data sent to DRO OEM Code 39)
If Modbus Spindle AND Index Enabled And port = 1 Or 2 Then process RPM functions as normal. (Threading setting).
If Modbus Spindle AND Index Enabled AND Index port = 0 Then do not process RPM functions (don't interrupt any data sent to DRO OEM Code 39)
Or you could make it simpler and add the following functions to the SmoothStepper Plugin config page Spindle frame:
Check box for Modbus spindle.
Check box for using Modbus RPM read back or ignore Index (don't interrupt any data sent to DRO OEM Code 39)
How soon can you fix this bug?
-
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 (http://warp9td.com/files/SmoothStepper_v17a.zip)
Thanks,
Greg
-
One minor point. The Index can be on port 1, 2, or 3.
Greg
-
Greg,
There is a problem with the download file location as I am getting the following error:
404 Not Found
The requested URL (/files/SmoothStepper_v17a.zip) was not found on this server.
-
I'm sorry Peter. Should be OK now.
Greg
-
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.
Allow me to expand on this thought a bit as I think it is an important point. If you are threading or doing any other movements that are synchronized to the spindle speed than the index signal MUST go through the SmoothStepper. Since the SmoothStepper is the motion controller it has to synchronize the step pulses with the index pulse, the only way that will work is if the SS receives the index pulse directly.
-
Allow me to expand on this thought a bit as I think it is an important point. If you are threading or doing any other movements that are synchronized to the spindle speed than the index signal MUST go through the SmoothStepper. Since the SmoothStepper is the motion controller it has to synchronize the step pulses with the index pulse, the only way that will work is if the SS receives the index pulse directly.
Yes, this is correct if you are wanting to thread, but this is not the case here, there is no index sensor involved.
The VFD provides the spindle speed via modbus, which is far more convenient that adding a spindle index sensor and feeding it into the Smooth Stepper. The Smooth Stepper plugin should know that no index sensor has been configured and therefore not write to the spindle RPM variable.
I presume that this is now what the fixed plugin is doing.
Cheers,
Peter
-
Peter:
Yes, this is correct if you are wanting to thread,
I think that is exactly what I said, let me reread it...
Me:If you are threading or doing any other movements that are synchronized to the spindle speed than the index signal MUST go through the SmoothStepper.
Yep that is exacly what I said...
-
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
-
Greg,
The thread title is "SmoothStepper Modbus RPM DRO conflict". This problem occurs when there is no index sensor attached. To start talking about threading and synchronising index sensors just isn't relevent to this thread (it's a completely different topic) and just adds confusion.
An index sensor synchronisation is also required for threading through the parallel port. But, that's also not relevant to this thread either.
Cheers,
Peter
-
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