Re: [Emc-users] Modbus wiring

[Nicklas Karlsson]

> > > > ISO7421
> > >
> > > Now thats sweet, and a heck of a lot better thought out than the
> > > last such chip I looked at a decade ago.  Needs a 4 wire cable from
> > > each direction, but I don't see as that as a problem other than
> > > stealing the ground and  3.3 or 5 volts to run its side of it at
> > > both ends.
> > >
> > > That should indeed sove the noise problem.  The pcb requires a
> > > slightly different layout of putting the power on the center layers,
> > > so the best bet is to look around and see if someone might have it
> > > all boxed up and ready to connect.
> > >
> > > Were you able to find such a ready-made critter?  If so where?
> >
> > No I made my own circuit board, two layer. SO footprint should not be
> > to hard to solder there are small prototype boards or similar on
> > Farnell.
> >
> > http://se.farnell.com/roth-elektronik/re932-01/pcb-adaptor-smd-so-8-20
> >-5mmx8mm/dp/1426169
> > http://se.farnell.com/roth-elektronik/re932-03/adaptor-smd-so-14-1-27m
> >m/dp/1426171
> > http://se.farnell.com/roth-elektronik/re932-02/adaptor-smd-so-8w-1-27m
> >m/dp/1426170
> > http://se.farnell.com/roth-elektronik/re932-01st/multi-adapter-11-5x16
> >mm-soic-8/dp/2292022
> >
> > I do not have time to check if footprint is correct.
> >
> Immaterial as you wouls wire to suit, but all of them are missing a place 
> to put the recommended supply rail bypassing. And extra plated thru-hole 
> in each runner to the terminal would be nice.
> 
> But who is Farnell on this "west side" of the pond?  Or are they even 
> affiliated with anybody in the US?

Maybe it is newark http://www.newark.com/ otherwise I think digikey may be 
closer to you.

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Max acceleration/velocity (Limited by?)

[samco]

As easy as traj max vel = sqr(VmaxX^2+VmaxY^2+VmaxZ^2)


On Sun, 03 Apr 2016 16:54:45 -0500
 Jon Elson  wrote:
> On 04/03/2016 11:14 AM, Nicklas Karlsson wrote:
> > Then reading the configuration file I find there max acceleration and 
> > velocity is defined twice. They are defined in both [TRAJ] and [AXIS_?] 
> > sections.
> >
> > Does the trajectory planner follow the limit in it's own section? In such 
> > case what happen if [AXIS_?] limit is lower?
> >
> >
> If for instance the limits are higher on the X and Y axes 
> than the Z axis, If there is an X-Y move requested
> it can have a higher feed or acceleration than a move where 
> the Z was included.  So, you get to give max velocity and 
> accel for each axis, and then an overall max for all axes.  
> The T.P. will generate moves at the highest vel and accel 
> for the axes that are moving.
> 
> Jon
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Gene Heskett]

On Sunday 03 April 2016 18:12:28 Nicklas Karlsson wrote:

> > > ISO7421
> >
> > Now thats sweet, and a heck of a lot better thought out than the
> > last such chip I looked at a decade ago.  Needs a 4 wire cable from
> > each direction, but I don't see as that as a problem other than
> > stealing the ground and  3.3 or 5 volts to run its side of it at
> > both ends.
> >
> > That should indeed sove the noise problem.  The pcb requires a
> > slightly different layout of putting the power on the center layers,
> > so the best bet is to look around and see if someone might have it
> > all boxed up and ready to connect.
> >
> > Were you able to find such a ready-made critter?  If so where?
>
> No I made my own circuit board, two layer. SO footprint should not be
> to hard to solder there are small prototype boards or similar on
> Farnell.
>
> http://se.farnell.com/roth-elektronik/re932-01/pcb-adaptor-smd-so-8-20
>-5mmx8mm/dp/1426169
> http://se.farnell.com/roth-elektronik/re932-03/adaptor-smd-so-14-1-27m
>m/dp/1426171
> http://se.farnell.com/roth-elektronik/re932-02/adaptor-smd-so-8w-1-27m
>m/dp/1426170
> http://se.farnell.com/roth-elektronik/re932-01st/multi-adapter-11-5x16
>mm-soic-8/dp/2292022
>
> I do not have time to check if footprint is correct.
>
Immaterial as you wouls wire to suit, but all of them are missing a place 
to put the recommended supply rail bypassing. And extra plated thru-hole 
in each runner to the terminal would be nice.

But who is Farnell on this "west side" of the pond?  Or are they even 
affiliated with anybody in the US?

Thanks Nicklas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Nicklas Karlsson]

> > ISO7421
> 
> Now thats sweet, and a heck of a lot better thought out than the last 
> such chip I looked at a decade ago.  Needs a 4 wire cable from each 
> direction, but I don't see as that as a problem other than stealing the 
> ground and  3.3 or 5 volts to run its side of it at both ends.
> 
> That should indeed sove the noise problem.  The pcb requires a slightly 
> different layout of putting the power on the center layers, so the best 
> bet is to look around and see if someone might have it all boxed up and 
> ready to connect.
> 
> Were you able to find such a ready-made critter?  If so where?

No I made my own circuit board, two layer. SO footprint should not be to hard 
to solder there are small prototype boards or similar on Farnell.

http://se.farnell.com/roth-elektronik/re932-01/pcb-adaptor-smd-so-8-20-5mmx8mm/dp/1426169
http://se.farnell.com/roth-elektronik/re932-03/adaptor-smd-so-14-1-27mm/dp/1426171
http://se.farnell.com/roth-elektronik/re932-02/adaptor-smd-so-8w-1-27mm/dp/1426170
http://se.farnell.com/roth-elektronik/re932-01st/multi-adapter-11-5x16mm-soic-8/dp/2292022

I do not have time to check if footprint is correct.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Max acceleration/velocity (Limited by?)

[Jon Elson]

On 04/03/2016 11:14 AM, Nicklas Karlsson wrote:
> Then reading the configuration file I find there max acceleration and 
> velocity is defined twice. They are defined in both [TRAJ] and [AXIS_?] 
> sections.
>
> Does the trajectory planner follow the limit in it's own section? In such 
> case what happen if [AXIS_?] limit is lower?
>
>
If for instance the limits are higher on the X and Y axes 
than the Z axis, If there is an X-Y move requested
it can have a higher feed or acceleration than a move where 
the Z was included.  So, you get to give max velocity and 
accel for each axis, and then an overall max for all axes.  
The T.P. will generate moves at the highest vel and accel 
for the axes that are moving.

Jon

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Max acceleration/velocity (Limited by?)

[Gene Heskett]

On Sunday 03 April 2016 16:52:12 Nicklas Karlsson wrote:

> > On Sun, Apr 3, 2016, at 12:14 PM, Nicklas Karlsson wrote:
> > > Then reading the configuration file I find there max acceleration
> > > and velocity is defined twice. They are defined in both [TRAJ] and
> > > [AXIS_?] sections.
> >
> > I am reasonably certain that the TRAJ limits apply to the combined
> > motion of the controlled point, while the AXIS limits apply to the
> > individual axes.
> >
> > Consider a 45 degree move.  If X is moving at its limit of 10
> > units/sec and Y is also moving at its limit of 10 units/sec, the
> > controlled point is moving at 14.14 units/sec. If the TRAJ limit was
> > also 10, X and Y would be slowed down to 7.07 units/sec so that the
> > controlled point is moving at 10.
> >
> > > Does the trajectory planner follow the limit in it's own section?
> > > In such case what happen if [AXIS_?] limit is lower?
> >
> > I'm pretty sure lowest limit wins.
> >
> > Assume X limit is 6, Y limit is 8, and TRAJ limit is 9.
> > A move from (0,0) to (10,0) is parallel to X and would be limited to
> > 6. A move from (0,0) to (0,10) is parallel to Y and would be limited
> > to 8. A move from (0,0) to (12,16) would result in X moving at 5.4
> > units/sec and Y moving at 7.2 units/sec, so that the motion of the
> > controlled point is at 9 units/sec even though neither axis is at
> > its limit.
>
> Never thought about it before but interestingly enough it is possible
> to get sqrt(2) larger acceleration in the diagonal provided maximum
> acceleration is equal for both axis. For three axis it is sqrt(3)
> which is a quite large difference.

And that multiplier then is 1.73205080756887729.  Intriguing.

Do we set the [TRAJ] settings then to be that times the fastest axis, or 
the slowest one?  Seems to me we should use the fastest axis since a 
slower one will automatically restrain the speeds of the others so it 
can maintain a straight line path.

Interesting thread, do carry on. :)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Max acceleration/velocity (Limited by?)

[Nicklas Karlsson]

> On Sun, Apr 3, 2016, at 12:14 PM, Nicklas Karlsson wrote:
> > Then reading the configuration file I find there max acceleration and 
> > velocity is defined twice. They are defined in both [TRAJ] and [AXIS_?] 
> > sections.
> 
> I am reasonably certain that the TRAJ limits apply to the combined motion of 
> the 
> controlled point, while the AXIS limits apply to the individual axes.
> 
> Consider a 45 degree move.  If X is moving at its limit of 10 units/sec and Y 
> is also
> moving at its limit of 10 units/sec, the controlled point is moving at 14.14 
> units/sec.
> If the TRAJ limit was also 10, X and Y would be slowed down to 7.07 units/sec 
> so
> that the controlled point is moving at 10.
> 
> 
> > 
> > Does the trajectory planner follow the limit in it's own section? In such 
> > case what happen if [AXIS_?] limit is lower?
> > 
> 
> I'm pretty sure lowest limit wins.
> 
> Assume X limit is 6, Y limit is 8, and TRAJ limit is 9.
> A move from (0,0) to (10,0) is parallel to X and would be limited to 6.
> A move from (0,0) to (0,10) is parallel to Y and would be limited to 8.
> A move from (0,0) to (12,16) would result in X moving at 5.4 units/sec
> and Y moving at 7.2 units/sec, so that the motion of the controlled
> point is at 9 units/sec even though neither axis is at its limit.

Never thought about it before but interestingly enough it is possible to get 
sqrt(2) larger acceleration in the diagonal provided maximum acceleration is 
equal for both axis. For three axis it is sqrt(3) which is a quite large 
difference.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Gene Heskett]

On Sunday 03 April 2016 15:07:59 Nicklas Karlsson wrote:

> ISO7421

Now thats sweet, and a heck of a lot better thought out than the last 
such chip I looked at a decade ago.  Needs a 4 wire cable from each 
direction, but I don't see as that as a problem other than stealing the 
ground and  3.3 or 5 volts to run its side of it at both ends.

That should indeed sove the noise problem.  The pcb requires a slightly 
different layout of putting the power on the center layers, so the best 
bet is to look around and see if someone might have it all boxed up and 
ready to connect.

Were you able to find such a ready-made critter?  If so where?

Thanks Nicklas.

In the FWIW dept, I looked at the serial interface data for that VFD I 
bought, and IF the interface is present, its RS232. It runs at 9600 
baud, expects a 9 byte packet control packet, and sends back a 13 byte 
status packet, with a couple tables to show what byte means what.  Not 
exactly real time, but hey, its a spindle motor.  But I don't believe 
that little postage stamp sized card is in this one.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Nicklas Karlsson]

ISO7421 is two channel bidirectional, there are more of them with different 
configurations.


On Sun, 3 Apr 2016 14:30:50 -0400
Gene Heskett  wrote:

> On Sunday 03 April 2016 14:10:04 Nicklas Karlsson wrote:
> 
> > I tried opto isolators and they did not work without errors while
> > capacitive insulation barriers did. It was a suprise and I can't tell
> > why. I think most devices including opto have a limited dv/dt
> > tolerance.
> 
> Damn, old wet ram strikes again. :(
> 
> I had forgotten there are such beasts, no doubt with limited withstand, 
> but probably enough to stop most of the noise our stuff can make.
> 
> Can you share the jedec number of the device you used?  Others here might 
> find it extremely usefull.
> 
> Thanks Nicklas.
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Nicklas Karlsson]

> Floating-point numbers have a huge range due to the floating-point
> nature, but the dynamic range is limited. The mantissa of an IEEE 754
> double-precision float (8 bytes) has a width of 52 bits (not counting
> the sign). This gives 52/log2(10)=15.7 decimal digits of accuracy. For
> linear systems, this will almost never be a problem. Even if a machine
> has a travel range of 1km, the position can still be resolved down to
> approx. 222fm, which is something like 1/1000th of the diameter of an
> average atom.

This is certainly far more than needed even though resolution decrease at 
longer distance. Decimal point may be moved to get a small range or large 
number but number of significant bits stay the same.

> Cheers,
> Philipp

Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Gene Heskett]

On Sunday 03 April 2016 14:10:04 Nicklas Karlsson wrote:

> I tried opto isolators and they did not work without errors while
> capacitive insulation barriers did. It was a suprise and I can't tell
> why. I think most devices including opto have a limited dv/dt
> tolerance.

Damn, old wet ram strikes again. :(

I had forgotten there are such beasts, no doubt with limited withstand, 
but probably enough to stop most of the noise our stuff can make.

Can you share the jedec number of the device you used?  Others here might 
find it extremely usefull.

Thanks Nicklas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Gene Heskett]

On Sunday 03 April 2016 13:36:23 Danny Miller wrote:

> Well, if you have 2 differential wires with a simple optoisolator at
> the far end, ground noise/ground loops would have no effect
> whatsoever.  You don't need a ground. There would be no place to put a
> ground.  There are no common-mode issues.  The slave device's ground
> could be +300VDC above the master's ground.
>
> However, RS485 doesn't spec that way.   The ADAM isolator box I have
> probably has optos inside, but has to make an RS485 output- which is a
> low-voltage DC differential in relation to a known ground.
>
> Danny

To me, considering the low voltages rs-485 uses, compared to the light it 
up voltages the opto's need, is a total non-starter.  The RS-485 would 
have to be amplified to a several volt differential, at the source, and 
that used to drive a laser diode, and that sent down an optical fiber to 
a diode on the other end of the fiber, and that diodes output then level 
translated back to RS485 differentials.  Such a circuit could survive 
anything but a cut fiber or a power failure.  100kv of EMP from a nearby 
lightning strike wouldn't bother it.

> On 4/3/2016 5:21 AM, Nicklas Karlsson wrote:
> > On Sat, 2 Apr 2016 11:34:25 -0400
> >
> > Gene Heskett  wrote:
> >> ...
> >> Given all that, I do not see how, in a noisy industrial
> >> environment, or even here at the Heskett's home camp, it can be
> >> error free unless an optical translator, bidirectional, is used at
> >> BOTH devices terminals.
> >
> > I am not sure about the optical translators. Why however I can't
> > tell for sure.
> >
> >> ...
> >>
> >> The question then seems to be, is who makes these rs485 to opto
> >> fiber (or even to RJ45 jacks & cat5 or cat6 cable since it doesn't
> >> have this common mode noise problem that I am aware of),
> >> bidirectional translators and at what cost.
> >
> > Ethernet which use the RJ45 connector have tranformer for
> > insulation. I have experienced communication errors over Ethernet
> > then communicating with inverter.
> >
> >
> > Nicklas Karlsson
> >
> > 
> >-- Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Configuring TB6560 Stepper Drivers

[jeshua]

> On Apr 3, 2016, at 7:32 AM, Valerio Bellizzomi  wrote:
> 
> so now you can retry my config problably this time with luck :-)

HI Valerio,

It was pretty forgiving on the timing settings - we used the Sherline defaults.


Best,

Jeshua Lacock
Founder/Engineer
<3DTOPO.com>
GlassPrinted.com


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Philipp Burch]

Hi all,

I have to admit that I've not read the rest of the discussion, so please
excuse if that has already been said.

On 03.04.2016 19:09, Mark wrote:
> On 04/03/2016 12:41 PM, Jon Elson wrote:
>> On 04/03/2016 09:46 AM, Mark wrote:
>>> That's why in this theoretical discussion I asked to
>>> disregard the actual machine accuracy and presume you had
>>> the so-called perfect machine. What I was looking for was
>>> how precise/accurate/resolute the controller would be.
>> But, there is no "perfect machine".  All machines have some
>> system for measuring position, whether stepper motors or
>> encoders.  These MUST have some fixed resolution that can be
>> either moved to (stepper) or measured (encoders).  While
>> there are physical positions that exist BETWEEN these
>> resolved points, they cannot be moved to by the motion
>> control hardware.  So, all machines have a lower limit to
>> positional resolution.  In practically ALL cases, this is
>> much coarser than the numerical resolution used in LinuxCNC.

Floating-point numbers have a huge range due to the floating-point
nature, but the dynamic range is limited. The mantissa of an IEEE 754
double-precision float (8 bytes) has a width of 52 bits (not counting
the sign). This gives 52/log2(10)=15.7 decimal digits of accuracy. For
linear systems, this will almost never be a problem. Even if a machine
has a travel range of 1km, the position can still be resolved down to
approx. 222fm, which is something like 1/1000th of the diameter of an
average atom.

BUT: Problems may arise if the travel range is not effectively limited,
as is the case with rotative systems. So if using a double to measure
the angle of some high-speed drive shaft without wrapping (I.e. the
first revolution gives 360deg, the second 720deg, etc.), then it may be
possible to actually hit the accuracy limit of the double. Running this
shaft at 5rpm in the same direction with an angular resolution of 16
bit (approx. 0.005deg) will cause a degradation of accuracy after 954
days or about 2.5 years of continuous runtime. This is most likely still
far more than any such system will be able to continously run, but it's
not some insanely large figure which will never ever be reached.
And: Should the value ever be converted to single-precision
floating-point (like on a microcontroller instead of an x86 PC), the
mantissa is only 23 bits, reducing this dynamic range by 29 bits or a
factor of about 500M. So the system above will suffer of degraded
accuracy after only 154 milliseconds.

That being said, I personally very seldomly care about the precision of
a double when it comes to representing physical quantities. They are
usually just good enough.

Cheers,
Philipp



signature.asc
Description: OpenPGP digital signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Gene Heskett]

On Sunday 03 April 2016 09:38:59 Mark wrote:

> On 04/03/2016 09:28 AM, Dave Caroline wrote:
> > A number is a number regardless of trailing 0's, no affect on
> > accuracy or resolution.
> > Where users do get it wrong though, is not understanding how path
> > following has a tolerance. This is separate from the number and its
> > 0's but the speed of how you can change direction.
> > see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TrajectoryControl
> > and
> > http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64
> >
> > Dave Caroline
>
> Okay, assuming you have the theoretical perfect machine, what actually
> determines the accuracy and/or resolution?  To keep it simple, lets
> just assume straight line moves.
>
> Mark

All the springiness in the motor coupling or belt drive, the errors in 
the screws (which can be cumulative or canceling as thats usually rated 
at .001" per foot) and the nuts backlash, and the springing of the frame 
error caused by stiction at low speeds.  Overall thats difficult to 
measure but put a dial on the axis, and remove the backlash from the ini 
for that axis, then command a slow move, .01" a minute, and watch the 
dial, when it has moved to a convienient mark on the dial, write down 
the DRO readings, then move some more in the same direction to check for 
jerking moves which would be stiction, running it to the dials limit.

Then do an mdi move in the other direction back to the co-ordinate you 
wrote down. The dial won't come back to that mark, but the amount it 
lacks is pretty close to the backlash setting you should then put into 
the ini file for that axis.  Reset the dial to watch Y, wash rinse & 
repeat, ditto for Z.

As for mapping screws to compensate for their error, that would take an 
external DRO of known accuracy, something I do not have.  That level of 
accuracy is more lab standard stuff, and will need a childs wagonload of 
SBAnthony dollars to obtain.  And I don't even have the childs wagon. :(

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Nicklas Karlsson]

I tried opto isolators and they did not work without errors while capacitive 
insulation barriers did. It was a suprise and I can't tell why. I think most 
devices including opto have a limited dv/dt tolerance.



On Sun, 3 Apr 2016 12:36:23 -0500
Danny Miller  wrote:

> Well, if you have 2 differential wires with a simple optoisolator at the 
> far end, ground noise/ground loops would have no effect whatsoever.  You 
> don't need a ground. There would be no place to put a ground.  There are 
> no common-mode issues.  The slave device's ground could be +300VDC above 
> the master's ground.
> 
> However, RS485 doesn't spec that way.   The ADAM isolator box I have 
> probably has optos inside, but has to make an RS485 output- which is a 
> low-voltage DC differential in relation to a known ground.
> 
> Danny
> 
> On 4/3/2016 5:21 AM, Nicklas Karlsson wrote:
> > On Sat, 2 Apr 2016 11:34:25 -0400
> > Gene Heskett  wrote:
> >> ...
> >> Given all that, I do not see how, in a noisy industrial environment, or
> >> even here at the Heskett's home camp, it can be error free unless an
> >> optical translator, bidirectional, is used at BOTH devices terminals.
> > I am not sure about the optical translators. Why however I can't tell for 
> > sure.
> >
> >> ...
> >>
> >> The question then seems to be, is who makes these rs485 to opto fiber (or
> >> even to RJ45 jacks & cat5 or cat6 cable since it doesn't have this
> >> common mode noise problem that I am aware of), bidirectional translators
> >> and at what cost.
> > Ethernet which use the RJ45 connector have tranformer for insulation. I 
> > have experienced communication errors over Ethernet then communicating with 
> > inverter.
> >
> >
> > Nicklas Karlsson
> >
> > --
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> 
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Gene Heskett]

On Sunday 03 April 2016 09:37:05 Mark wrote:

> I understand that, but that doesn't really answer the question - what
> determines the machine/controller resolution/precision, the machine
> and electronics notwithstanding.  If I set the G Code coordinates to
> x.x is the resolution/accuracy actually 0.1" or is it 0.01" or 0.001"
> or something greater?
>
> Lets say the machine is at X 0.0 and Y 0.0.  The G Code commands a
> move to X 1.0 Y 0.0 (again in inches).  Does the machine move to that
> new position with a precision of 0.1", 0.01", 0.001" or something
> greater (using the theoretically perfect machine of course)?
>
> Does it make a difference if the G Code coordinates have one, two,
> three or more digits to the right of the decimal point?
>
> Mark
>
> On 04/03/2016 09:06 AM, John Thornton wrote:
> > http://linuxcnc.org/docs/2.7/html/gcode/overview.html#_number
> >
> > JT
> >
> > On 4/3/2016 7:48 AM, Mark wrote:
> >> Friend of mine and I have had an email discussion going over the
> >> last few days about movement precision, accuracy and resolution.
> >>
> >> Lets say there are three different G Code files, A, B and C.
> >>
> >> In file A, the coordinates are such:  X x.x Y x.x
> >>
> >> In file B, the coordinates are such: X x.xx Y x.xx
> >>
> >> In file C, the coordinates are such:  X x.xxx Y x.xxx
> >>
> >> For simplicity's sake, no Z axis and the units are inches.
> >>
> >> Using file A for example, with the coordinates only given with 0.1"
> >> precision, what exactly does the controller do?  Does it actually
> >> work to 0.1" precision or does it work to moreprecision, vis-a-vis
> >> when making moves?
> >>
> >> Is file C, with precision to three decimal places the standard
> >> precision in controllers, or do we just use three decimal places in
> >> the G Code because it's good enough for gummint workand the
> >> controller can actually make more precise moves (dependent of
> >> course on the machine, the mechanics and the electronics)?
> >>
> >> Mark

As others have said, the missing precision in the command is filled with 
zero's, clear down the the micro-step needed (for steppers anyway) to 
get X to 1.1000. In servo setups I'd assume the deadband is at least 
the backlash else it will hunt. So that in a servo setup, would probably 
be the major part of the actual positioning error.

How close it gets to that is up to the machines mechanical variables.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Gene Heskett]

On Sunday 03 April 2016 09:35:04 Nicklas Karlsson wrote:

[huge snip]

> You could also read if there is something in the manual about a
> shielded cable and how it should be connected.
>
>
> Nicklas Karlsson

Such information is not mentioned in my Chinglish manual.  And thats 
troublesome too IMO.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Danny Miller]

Well, if you have 2 differential wires with a simple optoisolator at the 
far end, ground noise/ground loops would have no effect whatsoever.  You 
don't need a ground. There would be no place to put a ground.  There are 
no common-mode issues.  The slave device's ground could be +300VDC above 
the master's ground.

However, RS485 doesn't spec that way.   The ADAM isolator box I have 
probably has optos inside, but has to make an RS485 output- which is a 
low-voltage DC differential in relation to a known ground.

Danny

On 4/3/2016 5:21 AM, Nicklas Karlsson wrote:
> On Sat, 2 Apr 2016 11:34:25 -0400
> Gene Heskett  wrote:
>> ...
>> Given all that, I do not see how, in a noisy industrial environment, or
>> even here at the Heskett's home camp, it can be error free unless an
>> optical translator, bidirectional, is used at BOTH devices terminals.
> I am not sure about the optical translators. Why however I can't tell for 
> sure.
>
>> ...
>>
>> The question then seems to be, is who makes these rs485 to opto fiber (or
>> even to RJ45 jacks & cat5 or cat6 cable since it doesn't have this
>> common mode noise problem that I am aware of), bidirectional translators
>> and at what cost.
> Ethernet which use the RJ45 connector have tranformer for insulation. I have 
> experienced communication errors over Ethernet then communicating with 
> inverter.
>
>
> Nicklas Karlsson
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Max acceleration/velocity (Limited by?)

[John Kasunich]

On Sun, Apr 3, 2016, at 12:14 PM, Nicklas Karlsson wrote:
> Then reading the configuration file I find there max acceleration and 
> velocity is defined twice. They are defined in both [TRAJ] and [AXIS_?] 
> sections.

I am reasonably certain that the TRAJ limits apply to the combined motion of 
the 
controlled point, while the AXIS limits apply to the individual axes.

Consider a 45 degree move.  If X is moving at its limit of 10 units/sec and Y 
is also
moving at its limit of 10 units/sec, the controlled point is moving at 14.14 
units/sec.
If the TRAJ limit was also 10, X and Y would be slowed down to 7.07 units/sec so
that the controlled point is moving at 10.


> 
> Does the trajectory planner follow the limit in it's own section? In such 
> case what happen if [AXIS_?] limit is lower?
> 

I'm pretty sure lowest limit wins.

Assume X limit is 6, Y limit is 8, and TRAJ limit is 9.
A move from (0,0) to (10,0) is parallel to X and would be limited to 6.
A move from (0,0) to (0,10) is parallel to Y and would be limited to 8.
A move from (0,0) to (12,16) would result in X moving at 5.4 units/sec
and Y moving at 7.2 units/sec, so that the motion of the controlled
point is at 9 units/sec even though neither axis is at its limit.

I am working from (ancient) memory - if knowing is important I would
suggest making a config with different limits and conducting some
experiments.  G0 moves run at the limits (I think), and halscope or
halmeter can be used to observe velocity.

-- 
  John Kasunich
  jmkasun...@fastmail.fm

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 12:41 PM, Jon Elson wrote:
> On 04/03/2016 09:46 AM, Mark wrote:
>> That's why in this theoretical discussion I asked to
>> disregard the actual machine accuracy and presume you had
>> the so-called perfect machine. What I was looking for was
>> how precise/accurate/resolute the controller would be.
> But, there is no "perfect machine".  All machines have some
> system for measuring position, whether stepper motors or
> encoders.  These MUST have some fixed resolution that can be
> either moved to (stepper) or measured (encoders).  While
> there are physical positions that exist BETWEEN these
> resolved points, they cannot be moved to by the motion
> control hardware.  So, all machines have a lower limit to
> positional resolution.  In practically ALL cases, this is
> much coarser than the numerical resolution used in LinuxCNC.
>
> Jon

Understood there's no "perfect " machine.  I was just looking for the 
ultimate theoretical accuracy/precision/resolution that could be gotten 
from the controller.  Which is why I didn't want to concern the 
discussion with the actual machine limitations.

This was started with basically a coffee table discussion on controller 
resolution.  My original query was worded poorly because I didn't know 
what I didn't know, to paraphrase a certain Secretary of Defense.  ;-)

Thanks all for the enlightenment.

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Jon Elson]

On 04/03/2016 09:46 AM, Mark wrote:
> That's why in this theoretical discussion I asked to 
> disregard the actual machine accuracy and presume you had 
> the so-called perfect machine. What I was looking for was 
> how precise/accurate/resolute the controller would be.
But, there is no "perfect machine".  All machines have some 
system for measuring position, whether stepper motors or 
encoders.  These MUST have some fixed resolution that can be 
either moved to (stepper) or measured (encoders).  While 
there are physical positions that exist BETWEEN these 
resolved points, they cannot be moved to by the motion 
control hardware.  So, all machines have a lower limit to 
positional resolution.  In practically ALL cases, this is 
much coarser than the numerical resolution used in LinuxCNC.

Jon

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Jon Elson]

On 04/03/2016 08:37 AM, Mark wrote:
> I understand that, but that doesn't really answer the question - what
> determines the machine/controller resolution/precision, the machine and
> electronics notwithstanding.  If I set the G Code coordinates to x.x is
> the resolution/accuracy actually 0.1" or is it 0.01" or 0.001" or
> something greater?
First, the entered coordinates are in "user units", which 
are definable when the system is configured.
mm and inch are the typical units.

Assuming a stepper-controlled machine, the limit is not 
mathematical, it can be moved to some discrete step on the 
motor. If servo-controlled, then the encoder resolution is 
the limit.  You cannot establish a position EXCEPT by 
reference to a stepper step or an encoder count.  These are 
usually THOUSANDS of times coarser than the internal numeric 
representation.
> Lets say the machine is at X 0.0 and Y 0.0.  The G Code commands a move
> to X 1.0 Y 0.0 (again in inches).  Does the machine move to that new
> position with a precision of 0.1", 0.01", 0.001" or something greater
> (using the theoretically perfect machine of course)?
It figures out the mathematical position requested, and then 
finds the closest position that can be achieved by the 
mechanical motion system and moves there.
> Does it make a difference if the G Code coordinates have one, two, three
> or more digits to the right of the decimal point?
>
>
We have already tried to make clear, it does NOT make a 
difference. All coordinates entered are immediately extended 
to the full double float precision.

Jon

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Jon Elson]

On 04/03/2016 07:48 AM, Mark wrote:
> Friend of mine and I have had an email discussion going over the last
> few days about movement precision, accuracy and resolution.
>
> Lets say there are three different G Code files, A, B and C.
>
> In file A, the coordinates are such:  X x.x Y x.x
>
> In file B, the coordinates are such: X x.xx Y x.xx
>
> In file C, the coordinates are such:  X x.xxx Y x.xxx
>
> For simplicity's sake, no Z axis and the units are inches.
>
> Using file A for example, with the coordinates only given with 0.1"
> precision, what exactly does the controller do?  Does it actually work
> to 0.1" precision or does it work to moreprecision, vis-a-vis when
> making moves?
>
>
All axis coordinates are extended to full 64-bit floating 
precision as the interpreter reads them.
So, 1 (no decimal), and 1.000 will end up as the same 
value internally.  Now, some odd numbers run into problems 
with their floating point representation, and so can't be 
printed out as cleanly as they were entered.
So, you can get numbers that show up on the screen with lots 
of digits to the right of the decimal point.
Such as 5 divided by 3 will give something like 
1.67 But, this is still represented internally 
to the greatest precision a double float can handle.  (Which 
will be more accurate than a wavelength of light, in most 
cases.)

So, specifying LOTS of zeros to the right of the decimal 
point accomplishes nothing.  In some cases, such as 
specifying arc start and end points, there can be problems 
determining the radius due to roundoff, so specifying more 
digits can help.  (Or, you can specify radius instead of I 
and J and never have that problem.)

Jon

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Max acceleration/velocity (Limited by?)

[Nicklas Karlsson]

Then reading the configuration file I find there max acceleration and velocity 
is defined twice. They are defined in both [TRAJ] and [AXIS_?] sections.

Does the trajectory planner follow the limit in it's own section? In such case 
what happen if [AXIS_?] limit is lower?

Regards Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 10:14 AM, Nicklas Karlsson wrote:
>> On 04/03/2016 09:31 AM, Nicklas Karlsson wrote:
 Lets say there are three different G Code files, A, B and C.

 In file A, the coordinates are such:  X x.x Y x.x

 In file B, the coordinates are such: X x.xx Y x.xx

 In file C, the coordinates are such:  X x.xxx Y x.xxx

 For simplicity's sake, no Z axis and the units are inches.

 Using file A for example, with the coordinates only given with 0.1"
 precision, what exactly does the controller do?  Does it actually work
 to 0.1" precision or does it work to moreprecision, vis-a-vis when
 making moves?

 Is file C, with precision to three decimal places the standard precision
 in controllers, or do we just use three decimal places in the G Code
 because it's good enough for gummint workand the controller can actually
 make more precise moves (dependent of course on the machine, the
 mechanics and the electronics)?

 Mark
>>> Machine resolution depend on for example: Movement for each step or micro 
>>> step for a stepper motor. Resolution of encoder for a motor with encoder. 
>>> Resolution may be degraded from this but if number of encoder pulses is 
>>> sent back to linuxcnc this should be the maximum resolution.
>>>
>>>
>>> Then it might be worth noting: Float point according to IEEE 754 is 23 bits 
>>> and double 53 bits regardless of decimal point position. Float work great 
>>> for values read from an analog to digital converter since number of 
>>> significant bits will be the same regardless of decimal point position 
>>> which vary depending on what value is representing.
>>>
>>> For float it may also be worth noting values will be closer together for 
>>> small values.
>>>
>>> Then unit is changed decimal point will be moved and there will be some 
>>> rounding errors so then using for machine control the question between 
>>> float and double will be. Is 23 bits resolution enough? Or is 53 bits 
>>> resolution needed? Are there any difference in computational speed?
>>>
>>>
>>> Regards Nicklas Karlsson
>> I get that, but let's assume the theoretically perfect machine.
>> Disregard the shortcomings of the stepper/drive, servo/drive, or any
>> slop and inaccuracy that would exist in the typical machine hardware
>> like bearings, etc.
> Machine accuracy because hardware is not perfect is a hard problem.
>
>
> Nicklas Karlsson

That's why in this theoretical discussion I asked to disregard the 
actual machine accuracy and presume you had the so-called perfect 
machine.  What I was looking for was how precise/accurate/resolute the 
controller would be.

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:42 AM, Dave Caroline wrote:
> we are all saying it makes NO difference how many trailing 0s you have
> the accuracy is machine and its maths, see Andy's answer
>
> Dave Caroline

It's a theoretical discussion, hence my usage of the theoretically 
perfect machine, which has no slop or limitations due to the electronics.

Andy's was the answer I was looking for.

Thanks everybody!

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:55 AM, andy pugh wrote:
> On 3 April 2016 at 14:47, Mark  wrote:
>
>> Okay, now we're getting somewhere.  Assuming the theoretically perfect
>> machine, a commanded move in a straight line (keeping it
>> simplified)would stop within
>>
>> x.x0" of it's commanded position, correct?
> Yes.
>
> Less theoretically, CAM systems that give arc coordinates to less than
> 3 figures of precision often fail the LinuxCNC arc consistency checks.
> So often you have to change the default precision to persuade LinuxCNC
> to draw the arc. (This is a consequence of pi being irrational)
>
Gotcha.  Thanks for the infoguys!

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Nicklas Karlsson]

> On 04/03/2016 09:31 AM, Nicklas Karlsson wrote:
> >> Lets say there are three different G Code files, A, B and C.
> >>
> >> In file A, the coordinates are such:  X x.x Y x.x
> >>
> >> In file B, the coordinates are such: X x.xx Y x.xx
> >>
> >> In file C, the coordinates are such:  X x.xxx Y x.xxx
> >>
> >> For simplicity's sake, no Z axis and the units are inches.
> >>
> >> Using file A for example, with the coordinates only given with 0.1"
> >> precision, what exactly does the controller do?  Does it actually work
> >> to 0.1" precision or does it work to moreprecision, vis-a-vis when
> >> making moves?
> >>
> >> Is file C, with precision to three decimal places the standard precision
> >> in controllers, or do we just use three decimal places in the G Code
> >> because it's good enough for gummint workand the controller can actually
> >> make more precise moves (dependent of course on the machine, the
> >> mechanics and the electronics)?
> >>
> >> Mark
> > Machine resolution depend on for example: Movement for each step or micro 
> > step for a stepper motor. Resolution of encoder for a motor with encoder. 
> > Resolution may be degraded from this but if number of encoder pulses is 
> > sent back to linuxcnc this should be the maximum resolution.
> >
> >
> > Then it might be worth noting: Float point according to IEEE 754 is 23 bits 
> > and double 53 bits regardless of decimal point position. Float work great 
> > for values read from an analog to digital converter since number of 
> > significant bits will be the same regardless of decimal point position 
> > which vary depending on what value is representing.
> >
> > For float it may also be worth noting values will be closer together for 
> > small values.
> >
> > Then unit is changed decimal point will be moved and there will be some 
> > rounding errors so then using for machine control the question between 
> > float and double will be. Is 23 bits resolution enough? Or is 53 bits 
> > resolution needed? Are there any difference in computational speed?
> >
> >
> > Regards Nicklas Karlsson
> 
> I get that, but let's assume the theoretically perfect machine. 
> Disregard the shortcomings of the stepper/drive, servo/drive, or any 
> slop and inaccuracy that would exist in the typical machine hardware 
> like bearings, etc.

Machine accuracy because hardware is not perfect is a hard problem.


Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[andy pugh]

On 3 April 2016 at 14:47, Mark  wrote:

> Okay, now we're getting somewhere.  Assuming the theoretically perfect
> machine, a commanded move in a straight line (keeping it
> simplified)would stop within
>
> x.x0" of it's commanded position, correct?

Yes.

Less theoretically, CAM systems that give arc coordinates to less than
3 figures of precision often fail the LinuxCNC arc consistency checks.
So often you have to change the default precision to persuade LinuxCNC
to draw the arc. (This is a consequence of pi being irrational)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Configuring TB6560 Stepper Drivers

[Valerio Bellizzomi]

On Sat, 2016-04-02 at 18:00 -0600, jeshua wrote:
> > On Mar 28, 2016, at 6:01 PM, Gene Heskett  wrote:
> > 
> > On Monday 28 March 2016 19:48:26 Gene Heskett wrote:
> > 
> >> On Monday 28 March 2016 16:21:36 jeshua wrote:
>  On Mar 26, 2016, at 7:50 AM, Sarah Armstrong
>   wrote:
>  
>  this all depends if you have connected the EN - ( enable - ) of
>  the stepper drives ,
>  all the + pins go to 5v
>  step -  = pul & dir - = direction
>  
>  if you have it's probable that you have this inverted or requires
>  inverting , for testing just leave this unconnected until you have
>  everything running beware some Bobs also require an enable input ,
>  although at first glance this particular board looks
>  straightforward
> >>> 
> >>> The motors go dead when I unplug the enable.
> >>> 
> > Which tells me they need an active enable, so hook the 5 volts to the + 
> > terminal, and something that goes to ground when LCNC is enabled to all 
> > the - enable terminals.  Or, just hard wire the - enable to ground them 
> > & leave them on.
> 
> Hi Gene,
> 
> Brilliant!!! You made one really happy person (plus gave me the satisfaction 
> of being able to help a friend) thanks to you!
> 
> That was it - we needed to run negative to al the negative terminals.
> 
> I wish you could have seen his face light up when we got the motor to move 
> the first time! Thank you!


so now you can retry my config problably this time with luck :-)

> 
> Cheers,
> 
> Jeshua Lacock
> Founder/Engineer
> <3DTOPO.com>
> GlassPrinted.com



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:34 AM, andy pugh wrote:
> On 3 April 2016 at 13:48, Mark  wrote:
>
>> Using file A for example, with the coordinates only given with 0.1"
>> precision, what exactly does the controller do?  Does it actually work
>> to 0.1" precision or does it work to moreprecision, vis-a-vis when
>> making moves?
> It will move from X x.x0 to X x.x0
>
> The internal representation is double-precision floating point mm.
> Double-precision has at least 15 digits of decimal precision.
> https://en.wikipedia.org/wiki/Double-precision_floating-point_format
>
> If someone was to make a micro-machining system that needed better
> than femtometer precision they would have to "lie" to the system and
> set up the feedback and scaling so that a G-code command of X10 moved
> 10nanometers (or whatever)
>
>
Okay, now we're getting somewhere.  Assuming the theoretically perfect 
machine, a commanded move in a straight line (keeping it 
simplified)would stop within

x.x0" of it's commanded position, correct?

Mark


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:31 AM, Nicklas Karlsson wrote:
>> Lets say there are three different G Code files, A, B and C.
>>
>> In file A, the coordinates are such:  X x.x Y x.x
>>
>> In file B, the coordinates are such: X x.xx Y x.xx
>>
>> In file C, the coordinates are such:  X x.xxx Y x.xxx
>>
>> For simplicity's sake, no Z axis and the units are inches.
>>
>> Using file A for example, with the coordinates only given with 0.1"
>> precision, what exactly does the controller do?  Does it actually work
>> to 0.1" precision or does it work to moreprecision, vis-a-vis when
>> making moves?
>>
>> Is file C, with precision to three decimal places the standard precision
>> in controllers, or do we just use three decimal places in the G Code
>> because it's good enough for gummint workand the controller can actually
>> make more precise moves (dependent of course on the machine, the
>> mechanics and the electronics)?
>>
>> Mark
> Machine resolution depend on for example: Movement for each step or micro 
> step for a stepper motor. Resolution of encoder for a motor with encoder. 
> Resolution may be degraded from this but if number of encoder pulses is sent 
> back to linuxcnc this should be the maximum resolution.
>
>
> Then it might be worth noting: Float point according to IEEE 754 is 23 bits 
> and double 53 bits regardless of decimal point position. Float work great for 
> values read from an analog to digital converter since number of significant 
> bits will be the same regardless of decimal point position which vary 
> depending on what value is representing.
>
> For float it may also be worth noting values will be closer together for 
> small values.
>
> Then unit is changed decimal point will be moved and there will be some 
> rounding errors so then using for machine control the question between float 
> and double will be. Is 23 bits resolution enough? Or is 53 bits resolution 
> needed? Are there any difference in computational speed?
>
>
> Regards Nicklas Karlsson

I get that, but let's assume the theoretically perfect machine. 
Disregard the shortcomings of the stepper/drive, servo/drive, or any 
slop and inaccuracy that would exist in the typical machine hardware 
like bearings, etc.

Just the controller.

If the G Code commands a straight line movement from X 0.0 Y 0.0 to X 
1.0 Y 0.0, disregarding accel and decel for the moment, is the 
precision/resolution of that move (in inches as before) 0.1", 0.01", 
0.001" or greater?

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Dave Caroline]

we are all saying it makes NO difference how many trailing 0s you have
the accuracy is machine and its maths, see Andy's answer

Dave Caroline

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:28 AM, Dave Caroline wrote:
> A number is a number regardless of trailing 0's, no affect on accuracy
> or resolution.
> Where users do get it wrong though, is not understanding how path
> following has a tolerance. This is separate from the number and its
> 0's but the speed of how you can change direction.
> see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TrajectoryControl
> and
> http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64
>
> Dave Caroline

Okay, assuming you have the theoretical perfect machine, what actually 
determines the accuracy and/or resolution?  To keep it simple, lets just 
assume straight line moves.

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

I understand that, but that doesn't really answer the question - what 
determines the machine/controller resolution/precision, the machine and 
electronics notwithstanding.  If I set the G Code coordinates to x.x is 
the resolution/accuracy actually 0.1" or is it 0.01" or 0.001" or 
something greater?

Lets say the machine is at X 0.0 and Y 0.0.  The G Code commands a move 
to X 1.0 Y 0.0 (again in inches).  Does the machine move to that new 
position with a precision of 0.1", 0.01", 0.001" or something greater 
(using the theoretically perfect machine of course)?

Does it make a difference if the G Code coordinates have one, two, three 
or more digits to the right of the decimal point?

Mark

On 04/03/2016 09:06 AM, John Thornton wrote:
> http://linuxcnc.org/docs/2.7/html/gcode/overview.html#_number
>
> JT
>
> On 4/3/2016 7:48 AM, Mark wrote:
>> Friend of mine and I have had an email discussion going over the last
>> few days about movement precision, accuracy and resolution.
>>
>> Lets say there are three different G Code files, A, B and C.
>>
>> In file A, the coordinates are such:  X x.x Y x.x
>>
>> In file B, the coordinates are such: X x.xx Y x.xx
>>
>> In file C, the coordinates are such:  X x.xxx Y x.xxx
>>
>> For simplicity's sake, no Z axis and the units are inches.
>>
>> Using file A for example, with the coordinates only given with 0.1"
>> precision, what exactly does the controller do?  Does it actually work
>> to 0.1" precision or does it work to moreprecision, vis-a-vis when
>> making moves?
>>
>> Is file C, with precision to three decimal places the standard precision
>> in controllers, or do we just use three decimal places in the G Code
>> because it's good enough for gummint workand the controller can actually
>> make more precise moves (dependent of course on the machine, the
>> mechanics and the electronics)?
>>
>> Mark


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Nicklas Karlsson]

> > Gene Heskett  wrote:
> > > On Saturday 02 April 2016 07:04:14 Nicklas Karlsson wrote:
> > > > > I had SERIOUS problems with my X200 VFD and RS485 bus- I
> > > > > "mostly" fixed it.
> > > > >
> > > > > Here's the thing- yes, RS485 is differential, but the VFD is
> > > > > probably NOT opto-isolated input.  Differential conveys strong
> > > > > noise immunity- but ONLY when both A and B wires' voltages are
> > > > > within the input range of the VFD's bus driver, which might be
> > > > > -0.5v to 7v relative to the ground on the VFD driver chip.
> > > > > Outside that range, it will NOT function.
> > > > >
> > > > > The X200 confuses me greatly.  Yes is has an A and B RS485
> > > > > terminals, but no ground on the RJ45 jack.  If you don't have a
> > > > > ground to connect to, this problem can easily come up, and DID. 
> > > > > I had to take apart the VFD to measure this- like >20v of noise
> > > > > between the PC ground and the VFD driver.  That will NOT work,
> > > > > and didn't.
> > > >
> > > > You just hit the major problem with switched power electronics,
> > > > common mode voltages. A common mode choke will increase common
> > > > mode impedance. Increased impedance will not by itself decrease
> > > > voltage but if some current could be conducted away the higher
> > > > impedance will however lower voltage. One problem is even though
> > > > ground resistance is close to zero impedance is not. I remember I
> > > > have read a value of 50µH as maximum power grid inductance but are
> > > > not totally sure this is correct and particular not for all
> > > > frequencies.
> > > >
> > > > Common mode voltage source is capacitance between switch power
> > > > electronics conductor with a "square" voltage and ground. It is
> > > > probably correct to think about it as a capacitor connected to
> > > > ground which is switched between the two rectified voltage
> > > > potentials.
> > > >
> > > > There is capacitor between: "square" voltage between inverter
> > > > transistors and cooling fin. In electric motor between phases and
> > > > ground.
> > > >
> > > >
> > > > Different insulation barrier technologies are more or less
> > > > tolerant to common mode voltage. I think capcitive insulation
> > > > barriers like these used in Texas Instruments ISO7421 are tolerant
> > > > against common mode voltage.
> > >
> > > ...
> > > Given all that, I do not see how, in a noisy industrial environment,
> > > or even here at the Heskett's home camp, it can be error free unless
> > > an optical translator, bidirectional, is used at BOTH devices
> > > terminals.
> >
> > I am not sure about the optical translators. Why however I can't tell
> > for sure.
> >
> > > ...
> > >
> > > The question then seems to be, is who makes these rs485 to opto
> > > fiber (or even to RJ45 jacks & cat5 or cat6 cable since it doesn't
> > > have this common mode noise problem that I am aware of),
> > > bidirectional translators and at what cost.
> >
> > Ethernet which use the RJ45 connector have tranformer for insulation.
> > I have experienced communication errors over Ethernet then
> > communicating with inverter.
> >
> >
> > Nicklas Karlsson
> 
> Well, in any event, it seems to me like it is time to get out the scope 
> and see if the interfering noise can be found.  If the noise is in the 
> VFD, I'd certainly contact the vendor for a solution.  Failing that, I 
> believe I'd get another VFD from a diferent source, and if it works, 
> then some bad publicity about the first one and lack of support should 
> be related here on this list.  This is not the only list of course, but 
> bad publicity  should cause a down tick in sales.  And that does send a 
> message.  You bought the product to USE it,  and if its not usable, warn 
> the rest of us.

You could also read if there is something in the manual about a shielded cable 
and how it should be connected.


Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[andy pugh]

On 3 April 2016 at 13:48, Mark  wrote:

> Using file A for example, with the coordinates only given with 0.1"
> precision, what exactly does the controller do?  Does it actually work
> to 0.1" precision or does it work to moreprecision, vis-a-vis when
> making moves?

It will move from X x.x0 to X x.x0

The internal representation is double-precision floating point mm.
Double-precision has at least 15 digits of decimal precision.
https://en.wikipedia.org/wiki/Double-precision_floating-point_format

If someone was to make a micro-machining system that needed better
than femtometer precision they would have to "lie" to the system and
set up the feedback and scaling so that a G-code command of X10 moved
10nanometers (or whatever)


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Nicklas Karlsson]

> Lets say there are three different G Code files, A, B and C.
> 
> In file A, the coordinates are such:  X x.x Y x.x
> 
> In file B, the coordinates are such: X x.xx Y x.xx
> 
> In file C, the coordinates are such:  X x.xxx Y x.xxx
> 
> For simplicity's sake, no Z axis and the units are inches.
> 
> Using file A for example, with the coordinates only given with 0.1" 
> precision, what exactly does the controller do?  Does it actually work 
> to 0.1" precision or does it work to moreprecision, vis-a-vis when 
> making moves?
> 
> Is file C, with precision to three decimal places the standard precision 
> in controllers, or do we just use three decimal places in the G Code 
> because it's good enough for gummint workand the controller can actually 
> make more precise moves (dependent of course on the machine, the 
> mechanics and the electronics)?
> 
> Mark

Machine resolution depend on for example: Movement for each step or micro step 
for a stepper motor. Resolution of encoder for a motor with encoder. Resolution 
may be degraded from this but if number of encoder pulses is sent back to 
linuxcnc this should be the maximum resolution.


Then it might be worth noting: Float point according to IEEE 754 is 23 bits and 
double 53 bits regardless of decimal point position. Float work great for 
values read from an analog to digital converter since number of significant 
bits will be the same regardless of decimal point position which vary depending 
on what value is representing.

For float it may also be worth noting values will be closer together for small 
values.

Then unit is changed decimal point will be moved and there will be some 
rounding errors so then using for machine control the question between float 
and double will be. Is 23 bits resolution enough? Or is 53 bits resolution 
needed? Are there any difference in computational speed?


Regards Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Dave Caroline]

A number is a number regardless of trailing 0's, no affect on accuracy
or resolution.
Where users do get it wrong though, is not understanding how path
following has a tolerance. This is separate from the number and its
0's but the speed of how you can change direction.
see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TrajectoryControl
and
http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64

Dave Caroline

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Gene Heskett]

On Sunday 03 April 2016 06:21:38 Nicklas Karlsson wrote:

> On Sat, 2 Apr 2016 11:34:25 -0400
>
> Gene Heskett  wrote:
> > On Saturday 02 April 2016 07:04:14 Nicklas Karlsson wrote:
> > > > I had SERIOUS problems with my X200 VFD and RS485 bus- I
> > > > "mostly" fixed it.
> > > >
> > > > Here's the thing- yes, RS485 is differential, but the VFD is
> > > > probably NOT opto-isolated input.  Differential conveys strong
> > > > noise immunity- but ONLY when both A and B wires' voltages are
> > > > within the input range of the VFD's bus driver, which might be
> > > > -0.5v to 7v relative to the ground on the VFD driver chip.
> > > > Outside that range, it will NOT function.
> > > >
> > > > The X200 confuses me greatly.  Yes is has an A and B RS485
> > > > terminals, but no ground on the RJ45 jack.  If you don't have a
> > > > ground to connect to, this problem can easily come up, and DID. 
> > > > I had to take apart the VFD to measure this- like >20v of noise
> > > > between the PC ground and the VFD driver.  That will NOT work,
> > > > and didn't.
> > >
> > > You just hit the major problem with switched power electronics,
> > > common mode voltages. A common mode choke will increase common
> > > mode impedance. Increased impedance will not by itself decrease
> > > voltage but if some current could be conducted away the higher
> > > impedance will however lower voltage. One problem is even though
> > > ground resistance is close to zero impedance is not. I remember I
> > > have read a value of 50µH as maximum power grid inductance but are
> > > not totally sure this is correct and particular not for all
> > > frequencies.
> > >
> > > Common mode voltage source is capacitance between switch power
> > > electronics conductor with a "square" voltage and ground. It is
> > > probably correct to think about it as a capacitor connected to
> > > ground which is switched between the two rectified voltage
> > > potentials.
> > >
> > > There is capacitor between: "square" voltage between inverter
> > > transistors and cooling fin. In electric motor between phases and
> > > ground.
> > >
> > >
> > > Different insulation barrier technologies are more or less
> > > tolerant to common mode voltage. I think capcitive insulation
> > > barriers like these used in Texas Instruments ISO7421 are tolerant
> > > against common mode voltage.
> >
> > ...
> > Given all that, I do not see how, in a noisy industrial environment,
> > or even here at the Heskett's home camp, it can be error free unless
> > an optical translator, bidirectional, is used at BOTH devices
> > terminals.
>
> I am not sure about the optical translators. Why however I can't tell
> for sure.
>
> > ...
> >
> > The question then seems to be, is who makes these rs485 to opto
> > fiber (or even to RJ45 jacks & cat5 or cat6 cable since it doesn't
> > have this common mode noise problem that I am aware of),
> > bidirectional translators and at what cost.
>
> Ethernet which use the RJ45 connector have tranformer for insulation.
> I have experienced communication errors over Ethernet then
> communicating with inverter.
>
>
> Nicklas Karlsson

Well, in any event, it seems to me like it is time to get out the scope 
and see if the interfering noise can be found.  If the noise is in the 
VFD, I'd certainly contact the vendor for a solution.  Failing that, I 
believe I'd get another VFD from a diferent source, and if it works, 
then some bad publicity about the first one and lack of support should 
be related here on this list.  This is not the only list of course, but 
bad publicity  should cause a down tick in sales.  And that does send a 
message.  You bought the product to USE it,  and if its not usable, warn 
the rest of us.

On the mix-n-match 1.5HP I just bought, there is a common point, but its 
labeled as the ccw end of a manual speed control potentiometer.  And I 
have been assured by the vendor that using that for a logic ground, I 
can feed the PWM straight into the arm of the pot as its well filtered 
internally for just that use.  It has 0-5 volt input range, and a 0-10 
volt range as separate terminals.

If that terminal exists on yours, then I would connect that terminal to 
the logic ground of your RS-485 driver circuitry.  That should solve any 
common mode out of range errors.  That's generally going to be the 
reason when the noise has exceeded the active range of the loads input 
comparators.  That range would be from say .5 volts above the logic 
ground, to .5 volts below the + supply rail of the receiver.  I have 
seen some chips claim to be able to go all the way to the rails, but I 
would not put a 5 nines dependable rating on such a circuit.

The reason for that is the substrate diodes in the receiver IC, will have 
a measurable turnoff recovery time, and could output the wrong logic 
level during that time. That would generate edge triggered noise that 
could easily upset the receivers intention of sampling in the center of 

Re: [Emc-users] Controller/machine resolution

[John Thornton]

http://linuxcnc.org/docs/2.7/html/gcode/overview.html#_number

JT

On 4/3/2016 7:48 AM, Mark wrote:
> Friend of mine and I have had an email discussion going over the last
> few days about movement precision, accuracy and resolution.
>
> Lets say there are three different G Code files, A, B and C.
>
> In file A, the coordinates are such:  X x.x Y x.x
>
> In file B, the coordinates are such: X x.xx Y x.xx
>
> In file C, the coordinates are such:  X x.xxx Y x.xxx
>
> For simplicity's sake, no Z axis and the units are inches.
>
> Using file A for example, with the coordinates only given with 0.1"
> precision, what exactly does the controller do?  Does it actually work
> to 0.1" precision or does it work to moreprecision, vis-a-vis when
> making moves?
>
> Is file C, with precision to three decimal places the standard precision
> in controllers, or do we just use three decimal places in the G Code
> because it's good enough for gummint workand the controller can actually
> make more precise moves (dependent of course on the machine, the
> mechanics and the electronics)?
>
> Mark
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Controller/machine resolution

[Mark]

Friend of mine and I have had an email discussion going over the last 
few days about movement precision, accuracy and resolution.

Lets say there are three different G Code files, A, B and C.

In file A, the coordinates are such:  X x.x Y x.x

In file B, the coordinates are such: X x.xx Y x.xx

In file C, the coordinates are such:  X x.xxx Y x.xxx

For simplicity's sake, no Z axis and the units are inches.

Using file A for example, with the coordinates only given with 0.1" 
precision, what exactly does the controller do?  Does it actually work 
to 0.1" precision or does it work to moreprecision, vis-a-vis when 
making moves?

Is file C, with precision to three decimal places the standard precision 
in controllers, or do we just use three decimal places in the G Code 
because it's good enough for gummint workand the controller can actually 
make more precise moves (dependent of course on the machine, the 
mechanics and the electronics)?

Mark


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Nets and parameters in *.hal files

[Nicklas Karlsson]

On Sun, 3 Apr 2016 11:54:16 +0100
andy pugh  wrote:

> On 3 April 2016 at 11:47, Nicklas Karlsson  
> wrote:
> > To load it and look at the list halcmd print work although to get something 
> > useful from it is a little bit harder but once the information is there it 
> > is solvable.
> 
> The -s switch might make processing the data easier
> http://linuxcnc.org/docs/2.7/html/man/man1/halcmd.1.html

Maybe but I where not able to add it to the normal configuration.

I guess it is the same information as is available in linuxcnc "Hal 
configuration"?

> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Nets and parameters in *.hal files

[andy pugh]

On 3 April 2016 at 11:47, Nicklas Karlsson  wrote:
> To load it and look at the list halcmd print work although to get something 
> useful from it is a little bit harder but once the information is there it is 
> solvable.

The -s switch might make processing the data easier
http://linuxcnc.org/docs/2.7/html/man/man1/halcmd.1.html

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Nets and parameters in *.hal files

[Nicklas Karlsson]

On Fri, 1 Apr 2016 17:51:23 -0500
Jeff Epler  wrote:

> No, there is no way to take a component and find out the pins
> and parameters it will create, except for loading it and looking at the
> lists halcmd can print.

To load it and look at the list halcmd print work although to get something 
useful from it is a little bit harder but once the information is there it is 
solvable.


Regards Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Modbus wiring

[Nicklas Karlsson]

On Sat, 2 Apr 2016 11:34:25 -0400
Gene Heskett  wrote:

> On Saturday 02 April 2016 07:04:14 Nicklas Karlsson wrote:
> 
> > > I had SERIOUS problems with my X200 VFD and RS485 bus- I "mostly"
> > > fixed it.
> > >
> > > Here's the thing- yes, RS485 is differential, but the VFD is
> > > probably NOT opto-isolated input.  Differential conveys strong noise
> > > immunity- but ONLY when both A and B wires' voltages are within the
> > > input range of the VFD's bus driver, which might be -0.5v to 7v
> > > relative to the ground on the VFD driver chip. Outside that range,
> > > it will NOT function.
> > >
> > > The X200 confuses me greatly.  Yes is has an A and B RS485
> > > terminals, but no ground on the RJ45 jack.  If you don't have a
> > > ground to connect to, this problem can easily come up, and DID.  I
> > > had to take apart the VFD to measure this- like >20v of noise
> > > between the PC ground and the VFD driver.  That will NOT work, and
> > > didn't.
> >
> > You just hit the major problem with switched power electronics, common
> > mode voltages. A common mode choke will increase common mode
> > impedance. Increased impedance will not by itself decrease voltage but
> > if some current could be conducted away the higher impedance will
> > however lower voltage. One problem is even though ground resistance is
> > close to zero impedance is not. I remember I have read a value of 50µH
> > as maximum power grid inductance but are not totally sure this is
> > correct and particular not for all frequencies.
> >
> > Common mode voltage source is capacitance between switch power
> > electronics conductor with a "square" voltage and ground. It is
> > probably correct to think about it as a capacitor connected to ground
> > which is switched between the two rectified voltage potentials.
> >
> > There is capacitor between: "square" voltage between inverter
> > transistors and cooling fin. In electric motor between phases and
> > ground.
> >
> >
> > Different insulation barrier technologies are more or less tolerant to
> > common mode voltage. I think capcitive insulation barriers like these
> > used in Texas Instruments ISO7421 are tolerant against common mode
> > voltage.
> ...
> Given all that, I do not see how, in a noisy industrial environment, or 
> even here at the Heskett's home camp, it can be error free unless an 
> optical translator, bidirectional, is used at BOTH devices terminals. 

I am not sure about the optical translators. Why however I can't tell for sure.

> ...
> 
> The question then seems to be, is who makes these rs485 to opto fiber (or 
> even to RJ45 jacks & cat5 or cat6 cable since it doesn't have this 
> common mode noise problem that I am aware of), bidirectional translators 
> and at what cost.

Ethernet which use the RJ45 connector have tranformer for insulation. I have 
experienced communication errors over Ethernet then communicating with inverter.


Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users