That's a bare unidirectional isolator. OK for RS232. Problem being,
Modbus is over RS422/RS485, a bidirectional protocol and there's a lot
of difficult problems in creating buffers of any sort. It doesn't know
which direction it's supposed to drive at any given time.
http://www.mouser.com/Sea
> > > > 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
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]
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 t
> > 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.
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
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
> 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 m
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 o
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 i
> 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 syst
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 strik
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 iss
> 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
-
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
>>> di
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 sep
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 differe
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 actuall
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
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
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
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 contr
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 ma
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
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 fil
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
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
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
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 positio
> 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.xx
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 system
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:
>
>
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
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 simp
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 applicatio
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
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 great
> > 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-isol
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.x000
> 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.
>
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
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 th
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.
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
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
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/doc
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
use
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
48 matches
Mail list logo