Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: stevesy on August 19, 2018, 02:29:39 PM
-
Equipment: ESS ethernet smoothstepper
Option 1: I have a project where I need to send G90 commands to the CNC. The increments would be very small 0.019685". How many G90 commands can i send in a second and how accurate would be the position reported back to Mach3 in that time frame?
I may need to adjust Z after each G90 command is executed so I need the exact X position at the time its processed.
Option 2: I'm at X=0, I send a G90 X10 command and I'm running at 60IPM. Will mach accurately report X current position as it traverses the 10"? If it will how often will I get that information back while its traversing that 10"?
I'm writing a remote control app that will use a laser displacement sensor (distance sensor) to measure distance from the object in Z as the X axis moves. I need to know how often I can get accurate information back to match the current X and Y with the distance reported back by the sensor.
Is the X and Y position calculated in Mach or reported back from the controller?
Thanks.
-
Hi,
how accurate would be the position reported back to Mach3 in that time frame?
Mach is not a feedback control system. So you can send it a given distance, it will move that distance within the limits
of accuracy of the machine. The DRO will show the distance you programmed, not necessarily the distance actually
traveled.
You could attach a linear scale to the axis and have Mach monitor that. Mach3 would read a linear scale at the macro pump rate,
about 40 times a second. Mach4 would read it at the PLC rate, about 200 times a second.
-
Hi,
how accurate would be the position reported back to Mach3 in that time frame?
Mach is not a feedback control system. So you can send it a given distance, it will move that distance within the limits
of accuracy of the machine. The DRO will show the distance you programmed, not necessarily the distance actually
traveled.
You could attach a linear scale to the axis and have Mach monitor that. Mach3 would read a linear scale at the macro pump rate,
about 40 times a second. Mach4 would read it at the PLC rate, about 200 times a second.
A linear scale? Do you mean a separate piece of equipment? - NVM, it is piece of equipment.
So no way to match up Mach's position with this sensor then. Is there a way to tell when the command is complete? So if I send a G90 command and know when its complete I could thne take a sensor reading then, and then issue another G90 command. If I can how many can I send in a second, 40 times?
-
Hi,
So no way to match up Mach's position with this sensor then
Yes that can be done, but t is not as straightforward as you assume. I assume from
your reply that you cannot attach a linear scale? That would be the most direct and accurate solution.
Note G90 is a positioning mode, not a motion code. If you want to travel at max axis speed you use G0 or if you wish to travel at the current feedspeed,F,
then use G1.
You could issue a series of commands moving 0.01 say each time and measure/record the Z distance between each move. The speed at which that would happen
is dependent on the acceleration capability of the axis.
Craig
-
Hi,
So no way to match up Mach's position with this sensor then
Yes that can be done, but t is not as straightforward as you assume. I assume from
your reply that you cannot attach a linear scale? That would be the most direct and accurate solution.
Note G90 is a positioning mode, not a motion code. If you want to travel at max axis speed you use G0 or if you wish to travel at the current feedspeed,F,
then use G1.
You could issue a series of commands moving 0.01 say each time and measure/record the Z distance between each move. The speed at which that would happen
is dependent on the acceleration capability of the axis.
Craig
I could attach a linear scale but I'm trying to keep cost down. Laser displacement sensors aren't cheap, so I already have a bit of investment in this project :)
Unfortunately I didn't think that Mach3 was not showing accurate position as it travels. In hindsight I guess I should have.
I'm more worried that the smoothstepper would be my bottleneck, if its just the acceleration of the axis then I think I would be fine. Unless of course I'm not seeing something I should again :)
-
Mach3's display only updates 10x per second. If you are doing this from a macro, it's often a good idea to wait 1/10-1/4 second before reading the DRO to make sure it's accurate.
If I had to guess, I'd say there's no way you can send 40 moves per second.
Remember, Mach3 is a buffered system. Meaning the current movement has already previously been sent to the ESS. So there is some delay built into the system.
There are a few things that the ESS can do in realtime, like monitor home switches, and probing inputs.
But I don't think there's any chance that it'll do what you want.
-
I guess joeaverage's idea of an encoder would work then. It's rack and pinion so maybe I can use a rotary encoder with arduino or something.
I can read the laser sensor at 50hz so even if I could get readings every 10th of a inch running at 60 IPM I could still get pretty accurate measurements. I could just divide 1/10 of an inch into the 5 readings I get from the sensor. I would imagine it would be within 0.5mm accuracy on the position of X as it traveled that distance which is plenty for something like wood.
I guess the only real way to tell is do it. I'll report back just for fun after this weekend. I have the sensor and the means to measure it now. I'll write the code for the remote control over the next week and post my results from the test.
-Steve
-
Just a quick update....
I'm getting reports back about every 0.2" at 60 IPM in simulation mode. So basically 5 per second. Not good at all for what I'm trying to do.
I guess I'll go get an encoder and work with that.
-
Hi,
try Mach4 its about five times faster.
You're up against the fact that Windows and therefore Mach is not a real time system. Even if you could induce Mach to read a signal at a faster rate
Windows will take its own time, and if you don't like it....tough. Windows it not and has never had any pretensions as a realtime system.
Do you strictly need Mach? The reason I ask is that if you don't require the trajectory versatility that Mach and Gcode offer could you not use a microcontroller?
If I understand your application you require your machine to advance in one axis at a given speed while you record the Z depth at the same time.
I presume you end up with a file of data points (x,z).
Craig
-
Yes I could use a microcontroller but I'm not familiar with sending commands to the CNC controller with anything other than Mach3. If you have a suggestion of where I could get a C# example of moving an axis with the smoothstepper that would be awesome. However, my understanding is the smoothestepper is running at 10hz, still too slow for the effort I would need to put into it I think.
Yes, you are correct. I'm basically going to do a raster running across X given a length and then stepping Y by say 0.5mm then scanning across X again getting Z with this laser displacement sensor that I can get readings from at 50hz (every 20ms).
I will use OpenGL to plot the data on the screen in a point cloud and build triangles for a mesh, then allow the user (Me) to save to an stl file. All that part is complete. Well, the prototype is complete. I can take a 2.5d point cloud and plot and save a mesh to a stl file. It's just getting the data accurately at the X/Y position where I'm a little stuck. I ordered a rotary encoder to hook up to the gantry so that should produce an accurate X position.
https://www.sparkfun.com/products/11102
IO https://numato.com/product/8-channel-usb-gpio-module-with-analog-inputs
-
Hi,
If you have a suggestion of where I could get a C# example of moving an axis with the smoothstepper that would be awesome
No such number....the smoothstepper expects P(oint)V(elocity)T(ime) data from the plugin and in a manufacturer specific format.
There has been some talk about Warp9 releasing a low level API which would allow you to microprogram the ESS but it may be a long while
before its ready.
I think your encoder idea is workable, although I think you have chosen to wrong encoder. The one you have linked to produces Grey code and
you will require a PC or micro to decode it. Why?
Just an ordinary A,B,Z differential encoder would hook to three inputs of the ESS and Mach can read the encoder directly and process it and display it in a DRO.
Craig
-
i have tryed the same Thing with a other user here from the Forum, he had an UC300 as Motion Controller.
i have tryed to get the Points "on the fly" with less sucess, because the update of the X or Y Position is to slow.
the only way to get a good result was do to the move, wait for the axis to standstill, and take then the measurement.
IMHO i would "walk the street" with an ARDUINO.
control stepper motor's with arduino is no Problem.
read a TTL Encoder with arduino is no Problem.
read a analog Input with arduino is no Problem.
then initiate the move read the Encoder and analog value and send it via Serial Interface.
ok that is a Little bit of ARDUINO programming to do, but it is not inpossible and very fast of tracking.
Thomas
btw i have written a wizard for the Point by Point digitizing, just let me know if you want to try it.
-
Just an ordinary A,B,Z differential encoder would hook to three inputs of the ESS and Mach can read the encoder directly and process it and display it in a DRO.
Craig
This encoder has the same outputs. I don't see why I couldn't use it with the ESS. I'm writing the remote control in C# so even if I had to capture the data myself through usb it shouldn't matter. Also, wouldn't I be limited to the 10hz output of the ESS. It seems I would be in the same boat I'm in now of not getting the data fast enough.
-
IMHO i would "walk the street" with an ARDUINO.
I would have to disconnect everything to use my new "feature". I'm trying to make this an on demand kind of thing.
The other thing main point of the project is to do this as a pass..meaning I don't stop moving. Otherwise it will take forever to scan something. The goal is 60IPM with 0.5mm resolution..
btw i have written a wizard for the Point by Point digitizing, just let me know if you want to try it.
Let me give it a try first..the funnest part of this is doing it. You know what I mean?
-
Hi,
re-reading the spec sheet on the encoder and there are both incremental (quadrature) models AND absolute (Grey code) models.
The ESS /Mach can read quadrature encoders but would require a decoder to read Grey code.
Rather depends on the model of encoder that you get.
Craig
-
Hi,
re-reading the spec sheet on the encoder and there are both incremental (quadrature) models AND absolute (Grey code) models.
The ESS /Mach can read quadrature encoders but would require a decoder to read Grey code.
Rather depends on the model of encoder that you get.
Craig
The one I bought is the CWZ3E it's 1200P/R
But doesn't the ESS only report at 10HZ to Mach3? I read that somewhere. If that's the case I will still only get a reading every 10th of an inch at 60IPM.
-
Hi,
kool, that looks like an incremental encoder thus if you wish Mach and ESS can read and display it directly.
You may be right about the 10Hz rate of the ESS.
I think you would be advised to make an enquiry on the Warp9 forum about that. I now use Mach4 for which I believe
the ESS reporting rate is very much higher.
The reasons that I would do that is that it is possible for Mach to generate a file of data points directly. There is a
probe file feature which could be useful to you.
Craig
-
I would have to disconnect everything to use my new "feature". I'm trying to make this an on demand kind of thing.
The other thing main point of the project is to do this as a pass..meaning I don't stop moving. Otherwise it will take forever to scan something. The goal is 60IPM with 0.5mm resolution..
ok i see, but i would say back on the ARDUINO road again.
there is a sample code for the Encoder on the supplieres Homepage to Count the Encoder pulses.
hook your laser distance sensor also up to the ARDUINO, and you can create a syncronised data stream
on the ARDUINO and send it via Serial Interface.
for the Moment you have hooked the laser to the PC, and any way you will take it will be allways not syncroniced.
the ARDUINO solution will ive the possibilty to use it as an ADDON at your existing machine.
this is just brainstorming
i can give you the wizard, no Problem, but it reqires that the laser is connected to your ESS.
Thomas
-
Hi,
I've just had a look at the default plugin frequency of the ESS Mach4 plugin, its 40 Hz. You can change this which allows Mach to respond faster
but it requires your PC to work faster.
If you were to use Mach4 and increase the plugin frequency to 60Hz, then at your intended 'scan speed' of 60ipm, or 25.4mm/sec:
distance between successive samples= 25.4 / 60
=0.42mm
So you could push the ESS into service if you used Mach4.
You have not said how the laser scanner works or more importantly how it signals it output.
Is it digital or analogue?
What vertical resolution do you require?
How often can you sample it?
If the laser output is digital or can be converted to digital with sufficient resolution Mach could read it and construct data entries in a file.
I imagine that Mach3 can do it, but I don't know (or care) about VB. Mach4 has Lua and a substantial API and to have Mach4 construct a data file
would be easy, even fun.
If you think that the ESS and/or Mach is too slow then a dedicated microcontroller is the way to go. I personally find the wee 8 bit Arduinos a PITA,
I use a Texas Instruments Lanchpad which is equipped with 90 MHz 32bit single cycle Floating Point processor with all the periphials you could ask
for to control rotating machinery. The Lauchpad has an opto isolated JTAG built in and is ready to rock, all the free development software from
Texas Instruments you can eat, for under $50. For instance the processor has a periphial to read quadrature encoders in hardware with minimal CPU
supervision.
Craig
-
Warp9
The ESS reads each input at about 30 MHz. It can easily read encoder signals of up to 4 MHz (however this greatly depends on the Break Out Board's input pins, since too much capacitance or resistance will limit the maximum signal rate).
The ESS reports this data back to Mach3 10 times every second (which is the hard coded plugin update rate in Mach3).
The ESS reports this data back to Mach4 40 times every second (which is the default plugin update rate in the Mach4 ESS config, but it can be changed).
So getting anything through ESS isn't going to work for my project in Mach3. Possibly Mach4 though.
-
This is a situation that really requires you to have access to the realtime layer of the control. (like guts of the ess)
Linuxcnc you can sense -> model -> act a _minimum_ of 1000 times a second. (1ms) Because the realtime bits are actually in the computer - you can do this.
Or re-invent the wheel with an arduino or such.
sam
-
Hi skunkworks,
my apologies to OP if this is off topic.
skunkworks:
I have seen that Linux CNC uses RealTime Extensions to achieve realtime performance. I also saw a video where at the end of the
installation of the Linux distro (with the RTE's) to test the realtime performance. The video of the system under test reported
'a jitter of 23ms'. This was reported to be normal and adequate for LinuxCNC.
Can you clarify what it was that I saw, I would not have thought that a communication loop which included 23ms jitter would have been
anything like sufficient for a realtime feedback controller?
Craig
-
23ms jitter would be bad... (Unusable). My guess is that it was actually 23us of jitter. This would be a average jitter for rtai real-time extensions.
Sam
Hi skunkworks,
my apologies to OP if this is off topic.
skunkworks:
I have seen that Linux CNC uses RealTime Extensions to achieve realtime performance. I also saw a video where at the end of the
installation of the Linux distro (with the RTE's) to test the realtime performance. The video of the system under test reported
'a jitter of 23ms'. This was reported to be normal and adequate for LinuxCNC.
Can you clarify what it was that I saw, I would not have thought that a communication loop which included 23ms jitter would have been
anything like sufficient for a realtime feedback controller?
Craig
-
Hi Sam,
My guess is that it was actually 23us of jitter
Yeah, that sounds better, I came away from watching that video a bit confused.....23ms jitter is rubbish, Mach4 and my ESS can beat that hands down
and even that is not fast enough for many applications.
Thanks for your reply.
My problem is that I don't really know anything about Linux thus much of the capabilities and flexibility of Linux and therefore LinuxCNC are beyond me.
I have a spare laptop and could be persuaded to install a Linux distro 'just for fun'.
Craig
-
An update from this weekend.
I had originally ordered this rotary encoder https://www.robotshop.com/en/6mm-rotary-encoder-1024-p-r.html
For some reason the order failed to go through so I ended up ordering this one from Amazon. It's half the resolution but I just needed it for testing.
https://www.amazon.com/Signswise-Incremental-Encoder-Dc5-24v-Voltage/dp/B00UTIFCVA/ref=sr_1_1?s=hi&ie=UTF8&qid=1535373946&sr=8-1&keywords=Signswise+600&dpID=41%252BwuyVZcKL&preST=_SX300_QL70_&dpSrc=srch
I tried to use this IO board assuming it would work with the encoder
https://numato.com/product/8-channel-usb-gpio-module-with-analog-inputs
The Numato GPIO isn't nearly fast enough to keep up with the encoder and it was skipping ticks (readings or whatever).
I had a Arduino Uno that I ordered for another project but never used. I've never used Arduino and just assumed it would be super slow. I mean how fast can a $11 microcontroller be? Well, a heck of a lot faster than the Numato GPIO it turns out.
I used a couple of 10k resistors used the digitalWriteFast library found at https://code.google.com/archive/p/digitalwritefast/downloads and I was able to read every tick of the encoder without issue no matter how fast I turned it. I should have started off using the Arduino to begin with.(http://[img][img])[/img][/img]
My next problem was trying to get a gear that matched my rack (20 pitch, 20 pressure angle) with a 6mm bore. I know nothing about gears and assumed this would be easy, it wasn't. Even finding a gear that fit the rack was ridiculously hard. There's way more options to how a gear fits to another gear or rack than I imagined. The only one I could find was on Amazon and it was out of stock. So I tried to order a gear from Grainger with a 20 pitch but a 14.5 pressure angle with an 8mm bore and hoped I could rig it up. Well, they sent the right box but the gear was wrong. I guess someone switch them or something so I was stuck.
I thought I have a CNC why not just make one? Well, this turned out to be REALLY hard because its not straight forward. I ended up finding the site https://geargenerator.com/#200,200,100,6,1,0,0,4,1,8,2,4,27,-90,0,0,16,4,4,27,-60,1,1,12,1,12,20,-60,2,0,60,5,12,20,0,0,0,2,-563
I paid the $2, downloaded the svg. Converted it to EPS and imported it into ArtCam and cut it out of 1/2" polycarbonate. This turned out perfect, I get 0.005" resolution with it. I should have done this begin with. It would have saved me $25 from Grainger and numerous hours of research. Hind-sight is 20/20 though.
So that's all I was able to do this weekend. I'm going to try and find time next weekend. I'm pretty busy at work these days.
Encoder Gear:
https://drive.google.com/open?id=1FmpiZ8SHy31yYGcKkz6RTFFB5bpI9Ock
https://drive.google.com/open?id=1hm1z2rrhRfzgw8T3IWZb5HrzzyN9TS00
-
Here's the Arduino Sketch for the encoder. Maybe someone might find it useful.
#include <digitalWriteFast.h> // library for high performance reads and writes by jrraines
// see http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1267553811/0
// and http://code.google.com/p/digitalwritefast/
// Quadrature encoder
#define c_EncoderPinA 8
#define c_EncoderPinB 7
volatile bool _EncoderASet;
volatile bool _EncoderBSet;
volatile long _EncoderTicks = 0;
volatile bool _lastATick;
volatile bool _lastBTick;
void setup()
{
Serial.begin(115200);
pinMode(c_EncoderPinA, INPUT); // sets pin A as input
digitalWrite(c_EncoderPinA, LOW); // turn on pullup resistors
pinMode(c_EncoderPinB, INPUT); // sets pin B as input
digitalWrite(c_EncoderPinB, LOW); // turn on pullup resistors
}
void loop()
{
_EncoderASet = digitalReadFast(c_EncoderPinA); // read the input pin
_EncoderBSet = digitalReadFast(c_EncoderPinB); // read the input pin
// If the previous and the current state of the outputA are different, that means a Pulse has occured
if (_EncoderASet != _lastATick)
{
// If the outputB state is different to the outputA state, that means the encoder is rotating clockwise
if (_EncoderBSet != _EncoderASet) {
_EncoderTicks ++;
}
else
{
_EncoderTicks --;
}
_lastATick = _EncoderASet;
_lastBTick = _EncoderBSet;
Serial.print(_EncoderTicks);
Serial.print("\n");
}
}