Re: [Emc-users] Spindle speed changes with threading.

[Peter C. Wallace]

On Mon, 18 Jan 2021, Gene Heskett wrote:


Date: Mon, 18 Jan 2021 23:36:37 -0500
From: Gene Heskett 
Reply-To: "Enhanced Machine Controller (EMC)"

To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Spindle speed changes with threading.

On Monday 18 January 2021 22:21:00 Peter C. Wallace wrote:


On Mon, 18 Jan 2021, Gene Heskett wrote:

But because once locked, its not a big deal if the cutting load
slows the spindle 25%, its still locked at that phase angle and it
will stay that way until the end of THAT cut stroke.  But if YOU
change the spindle speed, then YOU have changed the synch delay at
the start of the next stroke and that changes the cutter position as
it tracks the next stroke, cutting a wider groove with that next
stroke. If you speed it up, the extra cut is the back edge of the
tool because it synched later in the spindles rotation.


I dont think thats true, the initial delays do not affect the thread
past any initial issues when the thread starts.
This is because once synchronized, the Z is effectively in a
_position_ locked loop with spindle rotation relative to the
accumulated angle past the index. Changing the speed may change the
start of the threads due to the lock-in time but not that main
threading pass. You can verify this by turning the spindle by hand and
doing multiple threading passses.


This is true of both G76 and G33.1, with G33.1 maintaining sync until the
tap has been totally withdrawn, while G76 releases the synch during the
Z retrace, so it can move at G0 speed, then both checks spindle-at-speed
and if true, starts the next pass on the index if you've written a peck
loop, exactly the same as for a single pass if your spindle has the
hueavos to do it in one pass.

Hidden in this is the fact that either resyncs the spindle to z phaseing
at the starting/resting place for either a G76 or a g33.1 for every
stroke it makes. And a change in spindle speed will change that phasing,
screwing up the thread.


I dont think so, both G33 and G76  are _position_ locked so the initial
start of thread may vary but the thread phasing is independent of spindle
speed.


Peter Wallace
Mesa Electronics


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

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Monday 18 January 2021 22:21:00 Peter C. Wallace wrote:

> On Mon, 18 Jan 2021, Gene Heskett wrote:
> > But because once locked, its not a big deal if the cutting load
> > slows the spindle 25%, its still locked at that phase angle and it
> > will stay that way until the end of THAT cut stroke.  But if YOU
> > change the spindle speed, then YOU have changed the synch delay at
> > the start of the next stroke and that changes the cutter position as
> > it tracks the next stroke, cutting a wider groove with that next
> > stroke. If you speed it up, the extra cut is the back edge of the
> > tool because it synched later in the spindles rotation.
>
> I dont think thats true, the initial delays do not affect the thread
> past any initial issues when the thread starts.
> This is because once synchronized, the Z is effectively in a
> _position_ locked loop with spindle rotation relative to the
> accumulated angle past the index. Changing the speed may change the
> start of the threads due to the lock-in time but not that main
> threading pass. You can verify this by turning the spindle by hand and
> doing multiple threading passses.
>
This is true of both G76 and G33.1, with G33.1 maintaining sync until the 
tap has been totally withdrawn, while G76 releases the synch during the 
Z retrace, so it can move at G0 speed, then both checks spindle-at-speed 
and if true, starts the next pass on the index if you've written a peck 
loop, exactly the same as for a single pass if your spindle has the 
hueavos to do it in one pass.

Hidden in this is the fact that either resyncs the spindle to z phaseing 
at the starting/resting place for either a G76 or a g33.1 for every 
stroke it makes. And a change in spindle speed will change that phasing, 
screwing up the thread.

So the spindle does not stay synced with Z during the entirety of a G76, 
each of the pass cuts is a fresh sync.  And If you have to write a peck 
loop for tappping because you don't have a 20 horse spindle it is also 
freshly resynced at the top of each g33.1. I usually stretch that top 
stop long enough to blow most of the swarf off the spinning tap, and to 
give it a drink of rapid tap or buttercut. It Helps to keep the tap from 
packing full.

> Peter Wallace
> Mesa Electronics
>
>
>
> ___
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


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

Re: [Emc-users] Spindle speed changes with threading.

[Peter C. Wallace]

On Mon, 18 Jan 2021, Gene Heskett wrote:


But because once locked, its not a big deal if the cutting load slows the
spindle 25%, its still locked at that phase angle and it will stay that
way until the end of THAT cut stroke.  But if YOU change the spindle
speed, then YOU have changed the synch delay at the start of the next
stroke and that changes the cutter position as it tracks the next
stroke, cutting a wider groove with that next stroke. If you speed it
up, the extra cut is the back edge of the tool because it synched later
in the spindles rotation.


I dont think thats true, the initial delays do not affect the thread
past any initial issues when the thread starts.
This is because once synchronized, the Z is effectively in a _position_
locked loop with spindle rotation relative to the accumulated angle
past the index. Changing the speed may change the start of the threads
due to the lock-in time but not that main threading pass. You can verify this
by turning the spindle by hand and doing multiple threading passses.



Peter Wallace
Mesa Electronics



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

Re: [Emc-users] Spindle speed changes with threading.

[Kirk Wallace]

On 1/18/21 3:53 PM, Andy Pugh wrote:



On 18 Jan 2021, at 23:08, John Dammeyer  wrote:

So what does LinuxCNC do?  Is the thread mucked up if spindle speed is changed 
during a feed hold and then start?

I believe that it does. The docs specifically warn against Chang speed during a 
threading cycle.



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




I seem to recall that lathe threading with G76 will disable the feed 
hold signal during the coordinated motion on the drive line, which can 
include the straight thread or an optional beginning or end taper within 
the stock straight thread length. The electronic gearing between the 
spindle encoder and the Z position should keep the thread path accurate 
through spindle speed variations. G33 documentation indicates that the 
routine calculates the best path to get the tool to the ideal index 
keyed path as soon as possible after the index mark signal. This is 
mostly from memory, so please refer to the LinuxCNC documentation to get 
the official information. I very much suggest _reading_ the 
documentation and not skimming because some of the features are not 
intuitive.


There are other ways to tread, such as using spindle index only with 
dead-reckoning.



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

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Monday 18 January 2021 18:47:25 John Dammeyer wrote:

> > > So what does LinuxCNC do?  Is the thread mucked up if spindle
> > > speed is changed during a feed hold and then start?
> >
> > Feed hold has nothing to do with it John, you can't change the
> > spindle speed in mid thread. Full stop. Period. I think it could do
> > what is needed.  But its like Yogi Berra once said about theory and
> > practice. Which in this case means machine balistics are hard to do.
>
> Gene,
> Are you saying that for threading on a lathe LinuxCNC _must_ have
> control over the spindle speed?  Or can I have a manual knob and
> adjust the speed as it's threading.  Or as it's returning back to the
> start?

No, you do not need linuxcnc control over spindle speed, I have no 
software linkage to control the spindle speed on any of my machines, but 
the spindle speed is very tightly regulated by a PID on 2 of my 
machines, and by the slip angle between the vfd and the spindle motor on 
the other 2, but IF you change the speed mid thread, you will change the 
phasing between the spindle and the tool because it takes a finite time 
to bring the z axis into synch with the spindle speed as it starts the 
next stroke. The Z is at a complete stop when the index arrives, and it 
takes some 10's of degrees for the z speed to arrive at the correct 
speed, and actually become locked to the spindle.

Change the spindle speed, and you change this delay to a greater effect 
than you would think because at a higher spindle speed, z has to reach a 
greater velocity, which takes more time. The position error once locked 
is more than 100% of the speed change, and can be almost square if 
doubleing the speed.

But because once locked, its not a big deal if the cutting load slows the 
spindle 25%, its still locked at that phase angle and it will stay that 
way until the end of THAT cut stroke.  But if YOU change the spindle 
speed, then YOU have changed the synch delay at the start of the next 
stroke and that changes the cutter position as it tracks the next 
stroke, cutting a wider groove with that next stroke. If you speed it 
up, the extra cut is the back edge of the tool because it synched later 
in the spindles rotation.

  Its the time it takes to accel to the locked state that eats your 
lunch.

> Or are you saying that if LinuxCNC is cutting a thread keep your
> fingers off the speed control?

Yes, cut air at a reduced speed to check your pullout point at the left 
end of the thread, and when checking, remember that the cutter is 
advancing to the left per stroke. not only in depth of cut, its normally 
taking 99% of the cut off the front (left) edge of the tool, that is 
what you are controlling with the Q setting in a G76. Normally 29.5 
degrees, the other .5 degree is to keep the top of the thread from 
smearing if your tool is dull. 30 degrees is perfect if the machine is, 
but you won't get quite as "clean" a cut because the back edge of the 
tool is skidding. At 29.5 for the advance angle, the right, back edge of 
the tools tooth is keeping things clean & smooth.

Cheers John, 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


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

Re: [Emc-users] Spindle speed changes with threading.

[Peter C. Wallace]

On Mon, 18 Jan 2021, John Dammeyer wrote:


Date: Mon, 18 Jan 2021 15:58:12 -0800
From: John Dammeyer 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "'Enhanced Machine Controller (EMC)'" 
Subject: Re: [Emc-users] Spindle speed changes with threading.

---


Just trying to get my head around this.  The spindle position is really only 
known by the index pulse.  Knowing both Z axis acceleration and target speed 
the Z is started N spindle encoder counts before an index pulse so it's up to 
speed the instant the spindle ticks over another index.  How many turns of the 
spindle that takes then doesn't matter.


John




AFAIK the Z position for threading is fully "geared"to the spindle position
during the entire threading pass so index is only used for initial sync. The Z 
position will alway be correct after the initial Z acceleration to reach

synchronization, regardless of the speed or change in speed of the spindle.

_But_ Changes at the beginning of the thread can occur with varying spindle 
speeds because of X and Z acceleration and velocity limits. These can change the 
start of thread position or even make threads with varing pitch if Z is not up 
to speed when cutting begins




Peter Wallace
Mesa Electronics



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

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Thanks Jon.

More questions below then.

> > Quick question about threading with LinuxCNC.  If you do a feed hold 
> > between passes for cutting a thread and during that feed hold
> change the spindle speed what will happen?
> >
> No problem.  At the beginning of EACH pass, the spindle
> encoder is zeroed and synched to the index pulse.  Then, the
> Z axis is slaved to the spindle count.  You can even stop or
> back up the spindle during the threading pass, and the Z
> will stay synched to the thread, within the backlash of the
> Z axis.
> 
> 
> > >From a start it takes a certain amount of time to accelerate up to the 
> > >required speed.  If the spindle is turning twice as fast as the
> previous pass it then turns twice as far.  That doesn't line up the cutter 
> with the previous thread.
> >
> Well, as speed increases, it needs more air cut travel to
> get synched, depending on the acceleration and performance
> of the Z axis.
> 
> Jon

Yeah I get that if it can't accelerate fast enough it does need to have the 
BEGIN position far enough away. 

I thought (someone said) that the threading only used the index once at the 
beginning of the threading operation.  I take it then that's per pass.  

I'm not sure what is meant by slaved to the spindle count.  If the Z axis was 
400 steps per rev and the spindle 60 pulses (240 quadrature edges).  Does the 
system calculate how many steps it requires to get up to the threading speed?  
Then use that to get to a specific spindle count value?

Maybe an example:
1.  For simplicity lead screw pitch of 10 TPI (0.1" pitch)
2. for 0.001" resolution the stepper motor has to have at least 100 steps per 
rev which is pretty easy with a motor running full step of 200 steps per turn.
3. Assume acceleration of 1000 steps/sec/sec. In 0.1 seconds it's doing 100 
steps/second. In 0.2 seconds 200 steps/second or 1 rev per second which is 60 
RPM.
4. Spindle is turning 60 RPM for threading so we've reached threading speed in 
0.2 seconds.
5. Spindle is turning 1 rev per second or 2/10ths of a rev in that 0.2 seconds. 
 (48 encoder counts of the 240 per rev) assuming the Z axis started on the 
index pulse with a cleared encoder counter.

Now let's double the spindle speed.   The lead screw also has to turn twice as 
fast so it will get there in 0.4 seconds.  But the spindle will have reached 48 
encoder counts in half the original time or 0.1 second.  It will have travelled 
much further before the Z axis is up to speed.

Or does LinuxCNC calculate that now it will take 96 spindle encoder counts to 
for the Z axis to get up to speed.  To enter the thread at the same point it 
then detects the index.  Counts 240-96 pulses and then starts the Z axis?

If it does that for any speed then the Z axis would always be synchronized on 
the next spindle index.

Just trying to get my head around this.  The spindle position is really only 
known by the index pulse.  Knowing both Z axis acceleration and target speed 
the Z is started N spindle encoder counts before an index pulse so it's up to 
speed the instant the spindle ticks over another index.  How many turns of the 
spindle that takes then doesn't matter.

John





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

Re: [Emc-users] Spindle speed changes with threading.

[Andy Pugh]

> On 18 Jan 2021, at 23:08, John Dammeyer  wrote:
> 
> So what does LinuxCNC do?  Is the thread mucked up if spindle speed is 
> changed during a feed hold and then start?

I believe that it does. The docs specifically warn against Chang speed during a 
threading cycle. 



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

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

> > So what does LinuxCNC do?  Is the thread mucked up if spindle speed is
> > changed during a feed hold and then start?
> >
> Feed hold has nothing to do with it John, you can't change the spindle
> speed in mid thread. Full stop. Period. I think it could do what is
> needed.  But its like Yogi Berra once said about theory and practice.
> Which in this case means machine balistics are hard to do.

Gene,
Are you saying that for threading on a lathe LinuxCNC _must_ have control over 
the spindle speed?  Or can I have a manual knob and adjust the speed as it's 
threading.  Or as it's returning back to the start? 

Or are you saying that if LinuxCNC is cutting a thread keep your fingers off 
the speed control?

John





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

Re: [Emc-users] Spindle speed changes with threading.

[Jon Elson]

On 01/18/2021 05:05 PM, John Dammeyer wrote:

Quick question about threading with LinuxCNC.  If you do a feed hold between 
passes for cutting a thread and during that feed hold change the spindle speed 
what will happen?
  
No problem.  At the beginning of EACH pass, the spindle 
encoder is zeroed and synched to the index pulse.  Then, the 
Z axis is slaved to the spindle count.  You can even stop or 
back up the spindle during the threading pass, and the Z 
will stay synched to the thread, within the backlash of the 
Z axis.




>From a start it takes a certain amount of time to accelerate up to the 
required speed.  If the spindle is turning twice as fast as the previous pass it 
then turns twice as far.  That doesn't line up the cutter with the previous thread.
  
Well, as speed increases, it needs more air cut travel to 
get synched, depending on the acceleration and performance 
of the Z axis.


Jon


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

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Monday 18 January 2021 18:05:56 John Dammeyer wrote:

> Quick question about threading with LinuxCNC.  If you do a feed hold
> between passes for cutting a thread and during that feed hold change
> the spindle speed what will happen?
>
> From a start it takes a certain amount of time to accelerate up to the
> required speed.  If the spindle is turning twice as fast as the
> previous pass it then turns twice as far.  That doesn't line up the
> cutter with the previous thread.
>
> The observation comment assumes a standard acceleration rate for the Z
> axis.
>
> However, the system could also be configured to accelerate up to
> arrive at a specific spindle position once it reaches threading speed.
>
> For example.  The system knows using the fastest Z axis
> acceleration+speed and spindle speed means it can arrive at threading
> speed in 30 degrees of spindle rotation.  At slower spindle speeds it
> would not accelerate so fast that it might be there at 5 degrees of
> spindle rotation.  Instead it would ramp up much slower so that when
> it reaches the much slower Z axis speed it also has reached the 30
> degree spindle position.
>
> At that point it doesn't matter anymore as long as the Z axis tracks
> the spindle speed the tool bit will follow the previous thread.
>
> So what does LinuxCNC do?  Is the thread mucked up if spindle speed is
> changed during a feed hold and then start?
>
Feed hold has nothing to do with it John, you can't change the spindle 
speed in mid thread. Full stop. Period. I think it could do what is 
needed.  But its like Yogi Berra once said about theory and practice. 
Which in this case means machine balistics are hard to do. 
> Thanks
> John Dammeyer
>
> "ELS! Nothing else works as well for your Lathe"
> Automation Artisans Inc.
> www dot autoartisans dot com
>
>
> ___
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


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

[Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Quick question about threading with LinuxCNC.  If you do a feed hold between 
passes for cutting a thread and during that feed hold change the spindle speed 
what will happen?
 
>From a start it takes a certain amount of time to accelerate up to the 
>required speed.  If the spindle is turning twice as fast as the previous pass 
>it then turns twice as far.  That doesn't line up the cutter with the previous 
>thread.
 
The observation comment assumes a standard acceleration rate for the Z axis.
 
However, the system could also be configured to accelerate up to arrive at a 
specific spindle position once it reaches threading speed.  
 
For example.  The system knows using the fastest Z axis acceleration+speed and 
spindle speed means it can arrive at threading speed in 30 degrees of spindle 
rotation.  At slower spindle speeds it would not accelerate so fast that it 
might be there at 5 degrees of spindle rotation.  Instead it would ramp up much 
slower so that when it reaches the much slower Z axis speed it also has reached 
the 30 degree spindle position.
 
At that point it doesn't matter anymore as long as the Z axis tracks the 
spindle speed the tool bit will follow the previous thread.  
 
So what does LinuxCNC do?  Is the thread mucked up if spindle speed is changed 
during a feed hold and then start?
 
Thanks
John Dammeyer
 
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot com 
 

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

Re: [Emc-users] Another Mesa vhdl question

[Ralph Stirling]

I have started looking at STMBL, but it is way, way more
complicated than I need at present, and will take some
care to strip it down to the essentials.  I was looking at
the STM32G031 soic-8 $1.72 part, which would be as
minimalist as possible, for the present purpose.
Too many ways to solve a problem :-).

-- Ralph

From: andy pugh [bodge...@gmail.com]
Sent: Monday, January 18, 2021 10:24 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Another Mesa vhdl question

On Mon, 18 Jan 2021 at 16:42, Ralph Stirling
 wrote:
>
> The AD7740 v-to-f converters don't work as well
> as I'd like, and I'm thinking about just using a
> little microcontroller, like the STM32G031 to do
> my A/D conversion.

One option there might be to use the STMBL source, that converts the
STM32 into a smart-serial device, that could pass the voltage as an
all-digital number straight to HAL.
(STMBL does far more than that too, but you wouldn't need all of it)

--
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, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C547b2bc89ca54ba7745808d8bbde71ad%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637465911357095541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iB80P%2FtA3M3oyAMk6R3T1oQoWGBTzQ4yEAOAvKwQHTA%3Dreserved=0


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

Re: [Emc-users] Another Mesa vhdl question

[andy pugh]

On Mon, 18 Jan 2021 at 16:42, Ralph Stirling
 wrote:
>
> The AD7740 v-to-f converters don't work as well
> as I'd like, and I'm thinking about just using a
> little microcontroller, like the STM32G031 to do
> my A/D conversion.

One option there might be to use the STMBL source, that converts the
STM32 into a smart-serial device, that could pass the voltage as an
all-digital number straight to HAL.
(STMBL does far more than that too, but you wouldn't need all of it)

--
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, 1912


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

Re: [Emc-users] Another Mesa vhdl question

[Peter C. Wallace]

On Mon, 18 Jan 2021, Ralph Stirling wrote:


Date: Mon, 18 Jan 2021 16:40:29 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "emc-users@lists.sourceforge.net" 
Subject: [Emc-users] Another Mesa vhdl question

The AD7740 v-to-f converters don't work as well
as I'd like, and I'm thinking about just using a
little microcontroller, like the STM32G031 to do
my A/D conversion.  While I could generate a
pulse train with frequency or period proportional
to voltage, I got to looking at bit files that include
a UART.  For the tiny amounts of data I need to
send, the simple UART with 115kbaud rate should
work fine at normal servo thread periods.

So, I have tried both stock *UA* bitfiles and a custom
bitfile with UART incorporated, and I get errors about
InstanceStride not matching expectations with either.

Turning on debug_idrom, I see that InstanceStride is
either 0x04 or 0x40, but the expected value is 0x10.
It isn't clear to me whether I want to select Instance
Stride 0 or 1 in my vhdl, but neither would match the
expected value.

hm2/hm2_7i90.0: Instance Stride 0: 0x0004
hm2/hm2_7i90.0: Instance Stride 1: 0x0040
hm2/hm2_7i90.0: Register Stride 0: 0x0100
hm2/hm2_7i90.0: Register Stride 1: 0x0100
hm2/hm2_7i90.0: inconsistent Module Descriptor for UART Transmit Channel, not 
loading driver
hm2/hm2_7i90.0: Version = 0, expected 0
hm2/hm2_7i90.0: NumRegisters = 4, expected 4
hm2/hm2_7i90.0: InstanceStride = 0x0040, expected 0x0010
hm2/hm2_7i90.0: MultipleRegisters = 0x000F, expected 0x000F
hm2/hm2_7i90.0: inconsistent Module Descriptor!
hm2/hm2_7i90.0: failed to parse Module Descriptor 4

Am I doing something wrong, has a bug crept into the
code, or is this just untested territory?  If it is a bug, is
it in the vhdl or the hostmot2 code?

Thanks again,
-- Ralph

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



Note that you can improve V-F readout performance by setting the
encoders "hires-timestamp" pin true

The UART requires the alternate instance stride (stride 1) set to 0x10
This is done in the top level file (its a awful kludge and means some
typs of modules cannot be combined)

I would suggest using the PKTUART instead as the PKTUART
uses standard instance strides (0= 0x04,1=0x40)

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

[Emc-users] Another Mesa vhdl question

[Ralph Stirling]

The AD7740 v-to-f converters don't work as well
as I'd like, and I'm thinking about just using a
little microcontroller, like the STM32G031 to do
my A/D conversion.  While I could generate a
pulse train with frequency or period proportional
to voltage, I got to looking at bit files that include
a UART.  For the tiny amounts of data I need to
send, the simple UART with 115kbaud rate should
work fine at normal servo thread periods.

So, I have tried both stock *UA* bitfiles and a custom
bitfile with UART incorporated, and I get errors about
InstanceStride not matching expectations with either.

Turning on debug_idrom, I see that InstanceStride is
either 0x04 or 0x40, but the expected value is 0x10.
It isn't clear to me whether I want to select Instance
Stride 0 or 1 in my vhdl, but neither would match the
expected value.

hm2/hm2_7i90.0: Instance Stride 0: 0x0004
hm2/hm2_7i90.0: Instance Stride 1: 0x0040
hm2/hm2_7i90.0: Register Stride 0: 0x0100
hm2/hm2_7i90.0: Register Stride 1: 0x0100
hm2/hm2_7i90.0: inconsistent Module Descriptor for UART Transmit Channel, not 
loading driver
hm2/hm2_7i90.0: Version = 0, expected 0
hm2/hm2_7i90.0: NumRegisters = 4, expected 4
hm2/hm2_7i90.0: InstanceStride = 0x0040, expected 0x0010
hm2/hm2_7i90.0: MultipleRegisters = 0x000F, expected 0x000F
hm2/hm2_7i90.0: inconsistent Module Descriptor!
hm2/hm2_7i90.0: failed to parse Module Descriptor 4

Am I doing something wrong, has a bug crept into the
code, or is this just untested territory?  If it is a bug, is
it in the vhdl or the hostmot2 code?

Thanks again,
-- Ralph

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