[Emc-users] On the status of BLDC component and Hostmot2

[John Prentice]

Greetings

I have an XY stage with Heidenhain linear encoders and BLDC motors on its 
screws. The encoders have built in interpolation giving a 0.08 micrometre 
resolution.

I have a Mesa 7i39 on its way.

There was a lot of BLDC work done by Andy Pugh around the turn of the year 
but so far as I can see everything is now very quiet.

If I pull 2.5-pre and compile it should I have everything needed (including 
a bitfile for Mesa 5i20)?

The motors are Elcom/Pittman Nema 23 frame (5111D008) - So far Google has 
not helped much! I plan to test initially with a rotary encoder as runaway 
on the XY table would be nasty.

Does anyone have any additional advice?

John Prentice 


--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] On the status of BLDC component and Hostmot2

[andy pugh]

On 15 August 2011 11:07, John Prentice  wrote:

> If I pull 2.5-pre and compile it should I have everything needed (including
> a bitfile for Mesa 5i20)?

There is an SVTP7_7i39 bitfile which I believe should arrive with a
apt-get install emc2-firmware (and which you might already have)
The current release (2.4.6) has the bldc_hall3 component, but doesn't
seem to have the three-phase PWM Hostmot2 function so you will need
2.5 to use the 7i39.

Rather than download/compile, you can install the precompiled package
from the buildbot, which is probably easier:
http://buildbot.linuxcnc.org/

Do you have Hall sensors on the motors?

If you don't have encoders or Hall sensors on the motors, but only
linear scales, then it is probably still possible to run the stage as
the relationship between stage position and motor rotor angle is
fixed. You will need to run the magnetic alignment routine in "bldc"
(loadrt bldc cfg=q ) and have the encoder scale set to the number of
linear scale counts per motor physical rev, with the correct motor
pole count parameter set in "bldc"

-- 
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] holes that aren't pefectly round

[John Thornton]

If you want perfectly round holes get a boring bar.

John

On 8/14/2011 4:56 PM, Chris Reynolds wrote:
> I'm using my Harbor Freight X2 mini mill. I converted it to cnc not long ago. 
> I don't cut a lot of circles with it but when I do I noticed they are not 
> perfectly round. I'll check for binding on the different axis, but I've never 
> had a problem with them binding in the past, the gibs might need adjusting 
> though.
>
>
> I guess maybe my next step would be to cut a circle with it and then find out 
> in which direction it's out of round, if I understood some of the replies 
> correctly. I recently checked and adjusted all axis for backlash and made the 
> necessary adjustments in the program, so my next thing will be to look at 
> binding, or play in the leadscrews.
>
>
>
>
>> What are you making the holes with?
>> It might be as simple as the machine being a lot more rigid in one
>> direction that in the other.
>>
>> This is definitely the case with my mini-mill, where the head can be
>> seen deflecting in the X direction but not in the Y.
> --
> FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
> Subversion made easy with a complete admin console. Easy
> to use, easy to manage, easy to install, easy to extend.
> Get a Free download of the new open ALM Subversion platform now.
> http://p.sf.net/sfu/wandisco-dev2dev
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] On the status of BLDC component and Hostmot2

[John Prentice]

> Rather than download/compile, you can install the precompiled package
> from the buildbot, which is probably easier:
> http://buildbot.linuxcnc.org/
>
> Do you have Hall sensors on the motors?
>
Andy, greetings

Thanks for the suggestion of Buildbot.

The motors do have Hall sensors. I thought that I would start "gently" with 
trapezoidal drive, then close the position loop with the encoders and 
finally see what happens to performance using sinusoidal. The encoder 
resolution is so high (effectively 25,000 counts per rev) that it seems 
there could be lots of traps.
The XY stage is obviously from some semiconductor fab. line, made by 
Newport, very stiff mechanically. It must have been servo controlled 
originally though I have no original electronics.

Finally a really dumb question. The 7i39 has SENSE A0/A1 and SENSE B0/B1 
outputs to FPGA board and these signals are on Pins 4/5 of the encoder 
interfaces. What are they for?

Best wishes

John Prentice 


--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] holes that aren't pefectly round

[andy pugh]

On 15 August 2011 12:28, John Thornton  wrote:
> If you want perfectly round holes get a boring bar.

In some cases a boring bar will work less well than
backlash-compensated spiral milling.

And in the case of a Mini Mill (and this is a Mini Mill) the
head/column stiffness is very different in X and Y directions, so you
get ovality even with the slides locked. This can be partially
compensated by taking tiny finishing cuts.

-- 
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] holes that aren't pefectly round

[John Thornton]

That does sound pretty weak, perhaps more hole than should be done on a 
mini mill.

John

On 8/15/2011 6:40 AM, andy pugh wrote:
> On 15 August 2011 12:28, John Thornton  wrote:
>> If you want perfectly round holes get a boring bar.
> In some cases a boring bar will work less well than
> backlash-compensated spiral milling.
>
> And in the case of a Mini Mill (and this is a Mini Mill) the
> head/column stiffness is very different in X and Y directions, so you
> get ovality even with the slides locked. This can be partially
> compensated by taking tiny finishing cuts.
>

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] holes that aren't pefectly round

[andy pugh]

On 15 August 2011 12:45, John Thornton  wrote:
> That does sound pretty weak, perhaps more hole than should be done on a
> mini mill.

To be fair, the rating plate says 30mm facing and 20mm end-milling, so
single-point boring 60mm in cast iron is probably pushing the envelope
too far. However, the problem exists at all scales, just to an extent
less obvious to the naked eye.


-- 
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] On the status of BLDC component and Hostmot2

[andy pugh]

On 15 August 2011 12:23, John Prentice  wrote:

> Finally a really dumb question. The 7i39 has SENSE A0/A1 and SENSE B0/B1
> outputs to FPGA board and these signals are on Pins 4/5 of the encoder
> interfaces. What are they for?

I think that is a question for PCW. I don't think that the Hostmot2
firmware does anything with them.

-- 
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] holes that aren't pefectly round

[gene heskett]

On Monday, August 15, 2011 07:49:47 AM John Thornton did opine:

> That does sound pretty weak, perhaps more hole than should be done on a
> mini mill.
> 
> John
> 
> On 8/15/2011 6:40 AM, andy pugh wrote:
> > On 15 August 2011 12:28, John Thornton  wrote:
> >> If you want perfectly round holes get a boring bar.
> > 
> > In some cases a boring bar will work less well than
> > backlash-compensated spiral milling.
> > 
> > And in the case of a Mini Mill (and this is a Mini Mill) the
> > head/column stiffness is very different in X and Y directions, so you
> > get ovality even with the slides locked. This can be partially
> > compensated by taking tiny finishing cuts.
 
When I built that new Z drive for my HF Micro Mill, I carved the bearing 
recesses in those alu blocks that you can see in the pix on my web page, 
with a 4 flute spiral upcut TiN plated solid carbide bit, switching to a 
fresh one for the last 2 or 3 passes.

Working with the backlash comp (adjusting that without having to reboot emc 
each time would be a god send) I was able to fit those ball thrust bearings 
that support the turning nuts to a snug, couldn't quite push them in by 
hand fit.  There is still about a .0002" ridge detectable at the xy 
reversal points when the bearings were pushed back out so I could take the 
measurements that make the grease zerk's align with a small hole in the 
bearing race (and it does, I can grease them with no problems), but the 
feel of turning the bearing in my hand vs once seated, remained the same.  
Aware of the higher flex in the X direction, the column was locked down 
tightly once the Z position was arrived at, and the last cuts made with 
about a .0002" inch increment in the size per pass and the cut was kept 
swimming in cutting oil to slow the alox formation that dulls tools.  
Literally swimming, it was sitting on a sheet of thin plywood that held the 
cutting oil in the hole quite nicely.

Maybe I was lucky, it worked.  OTOH, my measuring tool at the time was a 
fairly fresh 6" dial caliper with .001" graduations, not golden by any 
stretch. I generally use a digital version now, but IMO they are sloppier.

Maybe I got lucky, but it worked. As an ex Bro-in-law was fond of saying, 
it was good enough for the girls I go with. ;-)  And my Z drive can now 
bore holes with emc as it has about 155 pounds of push.  The OEM lashup of 
the Micro Mill binds to the column badly enough that it wasn't capable of 
more then 5 or 6 pounds of push, so the drill would sit and burn up.

Cheers, gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Money may buy friendship but money cannot buy love.

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Emc vs modern lcd monitors

[Przemek Klosowski]

On Sat, Aug 13, 2011 at 8:50 AM, gene heskett  wrote:

> One of the problems that was confusing me recently is that I had replaced
> the old samsung crt monitor with a much newer cheap AOC lcd that runs at
> 1360x724 at best, but under the vesa driver on an ati x1650 video card, it
> apparently is running in 1024x768.  This results in a pixel that is far
> from square unless I use a button on the monitor which shrinks the display
...
> (II) VESA(0): Not using mode "1360x768" (no mode of this name) <---native

If it really is 1360x768 (your log excerpt doesn't show it but seems
to be reported by the monitor, and it's pretty close to 16/9 wide
aspect ratio), you could add a custom mode in your  /etc/X11/xorg.conf
file. Something like:

Section "Monitor"
  Modeline "1360x768" 85.5 1360 1424 1536 1792 768 771 777 795
EndSection

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Anyone in Rio?

[andy pugh]

I have been asked to make 30 spinnaker anti-chafe trumpets for a fleet
of race yachts.
I confess I am not desperate to do it, and the timing is quite tight
(they need to get to the yachts when they arrive in Rio, currently
they are 300km north of the Cape Verde islands.

It occurs to me that having them made in Rio would save time, and
might be cheaper.
Do any of our Brazilian users have a CNC lathe?

-- 
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Emc vs modern lcd monitors

[Ed Nisley]

On Sat, 2011-08-13 at 08:50 -0400, gene heskett wrote:
> under the vesa driver on an ati x1650 video card

I ran into something like that on a Foxconn dual-core Atom D520 box that
I'm sliding under my Thing-O-Matic: the default video setup sent
1024x768 dots to a 1280x1024 monitor and didn't offer anything better.

The gotcha lay inside the Ubuntu 11.04 monitor settings, wherein
unchecking the "Show same thing on both monitors" box suddenly revealed
a second monitor! The Atom board has bone-stock Intel graphics with (to
the best of my knowledge) no second video output, but the second monitor
config showed all the myriad resolutions supported by the actual
display.

So I turned off the first monitor, picked 1280x1024 for the second
monitor, the LCD went *blink*, and it's now fine. BTSOOM.

Dunno if that applies to the VESA driver atop an ATI board, but it's
certainly worth checking.

-- 
Ed
http://softsolder.com



--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] 3d machine issue on new emc conversion

[For Sale Sticker]

> Sebastian wrote: 
> I didn't see the timing info in that spec sheet, but the quickref has some:
> 
> 
> 
> 

I need a little help understanding these numbers. There is some additional 
information on timing on page 13 and 15 of the document that Andy included 
(http://imshome.com/downloads/manuals/ib.pdf)

here is a link to just the screen shot of the timing info:

http://www.forsalesticker.com/ib106Timing-13.png
http://www.forsalesticker.com/ib106Timing-54.png


So to configure my timing correctly I need the following 4 values:

Step Time, Step Space, Direction Hold, Direction Setup.

I have made my best guess, using the info I have:

Step Time: 2000
Step Space: 3000
Direction Hold: 5500
Direction Setup: 2000

Are these even close to the numbers I should use?

Thanks




--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Emc vs modern lcd monitors

[gene heskett]

On Monday, August 15, 2011 05:15:23 PM Przemek Klosowski did opine:

> On Sat, Aug 13, 2011 at 8:50 AM, gene heskett  wrote:
> > One of the problems that was confusing me recently is that I had
> > replaced the old samsung crt monitor with a much newer cheap AOC lcd
> > that runs at 1360x724 at best, but under the vesa driver on an ati
> > x1650 video card, it apparently is running in 1024x768.  This results
> > in a pixel that is far from square unless I use a button on the
> > monitor which shrinks the display
> 
> ...
> 
> > (II) VESA(0): Not using mode "1360x768" (no mode of this name)
> > <---native
> 
> If it really is 1360x768 (your log excerpt doesn't show it but seems
> to be reported by the monitor, and it's pretty close to 16/9 wide
> aspect ratio), you could add a custom mode in your  /etc/X11/xorg.conf
> file. Something like:
> 
> Section "Monitor"
>   Modeline "1360x768" 85.5 1360 1424 1536 1792 768 771 777 795
> EndSection
> 
Many thanks, I just added that to the top of an extensive list in that 
machines xorg.conf, and I will go reboot it now for effects.

I tried variations of 1360x768 and 1366x768.  The log contains a long list 
of available modes, which do not include either of those, and are uniformly 
within a pixel of a 4x3 aspect ratio.  Does that list of modes come from 
the card?  Or from the vesa driver?

The log says 136nx768 is not used because there is no mode of that name 
even though I have added it to the "Monitor" section.

If its the card, I wonder if it is flashable to add that mode?

Or should I shelve the card, an ATI X1650 and replace it with something 
else that knows about 16x9 aspect ratios?

Thanks Przemek.

Cheers, gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"Bureaucracy is the enemy of innovation."
-- Mark Shepherd, former President and CEO of Texas Instruments

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Emc vs modern lcd monitors

[gene heskett]

On Monday, August 15, 2011 06:18:41 PM Ed Nisley did opine:

> On Sat, 2011-08-13 at 08:50 -0400, gene heskett wrote:
> > under the vesa driver on an ati x1650 video card
> 
> I ran into something like that on a Foxconn dual-core Atom D520 box that
> I'm sliding under my Thing-O-Matic: the default video setup sent
> 1024x768 dots to a 1280x1024 monitor and didn't offer anything better.
> 
> The gotcha lay inside the Ubuntu 11.04 monitor settings, wherein
> unchecking the "Show same thing on both monitors" box suddenly revealed
> a second monitor! The Atom board has bone-stock Intel graphics with (to
> the best of my knowledge) no second video output, but the second monitor
> config showed all the myriad resolutions supported by the actual
> display.
> 
> So I turned off the first monitor, picked 1280x1024 for the second
> monitor, the LCD went *blink*, and it's now fine. BTSOOM.
> 
> Dunno if that applies to the VESA driver atop an ATI board, but it's
> certainly worth checking.

I'll take a look, but remember this is running the vesa driver because the 
others wreck the real time.

Thanks Ed.

Cheers, gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
You will be held hostage by a radical group.

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Old ssh -Y problem is back

[rgrieger]

Ð
Sent via BlackBerry by AT&T

-Original Message-
From: Erik Christiansen 
Date: Mon, 1 Aug 2011 16:36:21 
To: 
Reply-To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Old ssh -Y problem is back

On 01.08.11 00:47, gene heskett wrote:
> On Monday, August 01, 2011 12:45:31 AM Kyle Kerr did opine:
> > On Mon, Aug 1, 2011 at 12:04 AM, gene heskett  wrote:
> > Ubuntu has a keyboard shortcut to access the terminal/konsole,
> > ctrl+alt+t.
>  
> And why has it taken me 8 or 9 years to hear that?  Thank you very much.

Gene, I'll +1 that. :-)

Despite preferring to use less effort than even ctrl+alt+t, with four
xterms being automatically started for me by gnome.

My ~/.gnomerc is:

#!/bin/bash
~/bin/xterms &# A script which starts 4 xterms, tiled to please.

 --

For just one, we could replace the xterms line with these:

col='-fg yellow -bg darkslategrey -cr red' # Colours
f='-fn 10x20'  # 3 mm fontsize
w=100  # Width
l=50   # Length

/usr/bin/xterm $col $f $scroll -geometry ${w}x${l}+0+80 &

 --

But if the additional script is used, it can also open mutt in an xterm
in the top right corner, with customised double-click character class
behaviour, so all of a URL is picked up by the mouse. (The left hand
terminal is made to pick up "Full pathnames, IPs, email addresses,
simple URLs, lhs or rhs of =", which suits me better for general use.
A third xterm for my on-line manual has other settings again, to better
pick up that kind of material.[1])

If a computer doesn't have at least one xterm open at all times, then
I'm at a loss to use it.

Erik

[1] Displayed/updated daily, using vim. Last night I added folding, so
that the 20,200 lines now display as 150 section headings, like a
TOC. That shows I could slightly tidy up what has accumulated over a
couple of decades.

-- 
Knowing all truth is less than doing a little bit of good.
  - Dr Albert Schweitzer


--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Emc vs modern lcd monitors

[Przemek Klosowski]

On Mon, Aug 15, 2011 at 6:06 PM, gene heskett  wrote:
> On Monday, August 15, 2011 05:15:23 PM Przemek Klosowski did opine:

>> Section "Monitor"
>>   Modeline "1360x768" 85.5 1360 1424 1536 1792 768 771 777 795
>> EndSection
>>
> Many thanks, I just added that to the top of an extensive list in that
> machines xorg.conf, and I will go reboot it now for effects.
>
> I tried variations of 1360x768 and 1366x768.  The log contains a long list
> of available modes, which do not include either of those, and are uniformly
> within a pixel of a 4x3 aspect ratio.  Does that list of modes come from
> the card?  Or from the vesa driver?

It's possible that your xorg.conf is messing you up---I bet you it's a
remnant of the old setup, and quite possibly not necessary. The long
list of modelines was how I learned to do X11 back in the days when we
had to whittle ones and zeros out of oak timbers but nowadays,
xorg.conf is just few lines long, and the Xorg server finds out the
video hardware, reads the monitor parameters over the video cable and
matches it to the built-in list of VESA standard modes. It'd be
interesting to try with a virgin minimalistic xorg.conf

Section "Device"
Identifier  "Videocard0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
EndSection

and maybe it'll figure something out on its own.  I don't know if
1360x768 is on the VESA list so maybe you do need it after all.


> The log says 136nx768 is not used because there is no mode of that name
> even though I have added it to the "Monitor" section.

It has to match the "Monitor" section your Screen section is using;
there could be multiple Monitor sections
("Monitor1","myOldCRT","LCDmonitor2", etc). Say something like

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "MyMonitor"
...
Section "Monitor"
  Identifier "MyMonitor"
  Modeline .
...

> If its the card, I wonder if it is flashable to add that mode?

Nope, I doubt it, every VGA card is capable of any resolution from
like 320x320 (?) to 8000x8000 (???) within the memory capabilities and
video clock speed; the limitations come from the monitor and driver
limitations.
>
> Or should I shelve the card, an ATI X1650 and replace it with something
> else that knows about 16x9 aspect ratios?

I will bet you a beer that your card is capable of driving your
monitor resolution.

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Emc vs modern lcd monitors

[gene heskett]

On Tuesday, August 16, 2011 12:02:31 AM Przemek Klosowski did opine:

> On Mon, Aug 15, 2011 at 6:06 PM, gene heskett  wrote:
> > On Monday, August 15, 2011 05:15:23 PM Przemek Klosowski did opine:
> >> Section "Monitor"
> >>   Modeline "1360x768" 85.5 1360 1424 1536 1792 768 771 777 795
> >> EndSection
> > 
> > Many thanks, I just added that to the top of an extensive list in that
> > machines xorg.conf, and I will go reboot it now for effects.
> > 
> > I tried variations of 1360x768 and 1366x768.  The log contains a long
> > list of available modes, which do not include either of those, and
> > are uniformly within a pixel of a 4x3 aspect ratio.  Does that list
> > of modes come from the card?  Or from the vesa driver?
> 
> It's possible that your xorg.conf is messing you up---I bet you it's a
> remnant of the old setup, and quite possibly not necessary. The long
> list of modelines was how I learned to do X11 back in the days when we
> had to whittle ones and zeros out of oak timbers but nowadays,
> xorg.conf is just few lines long, and the Xorg server finds out the
> video hardware, reads the monitor parameters over the video cable and
> matches it to the built-in list of VESA standard modes. It'd be
> interesting to try with a virgin minimalistic xorg.conf
> 
> Section "Device"
>   Identifier  "Videocard0"
> EndSection
> 
> Section "Screen"
>   Identifier "Screen0"
>   Device "Videocard0"
>   DefaultDepth 24
> EndSection
> 
> and maybe it'll figure something out on its own.  I don't know if
> 1360x768 is on the VESA list so maybe you do need it after all.
> 
> > The log says 136nx768 is not used because there is no mode of that
> > name even though I have added it to the "Monitor" section.
> 
> It has to match the "Monitor" section your Screen section is using;
> there could be multiple Monitor sections
> ("Monitor1","myOldCRT","LCDmonitor2", etc). Say something like
> 
> Section "Screen"
>   Identifier "Screen0"
>   Device "Videocard0"
> Monitor "MyMonitor"
> ...
> Section "Monitor"
>   Identifier "MyMonitor"
>   Modeline .
> ...
> 
> > If its the card, I wonder if it is flashable to add that mode?
> 
> Nope, I doubt it, every VGA card is capable of any resolution from
> like 320x320 (?) to 8000x8000 (???) within the memory capabilities and
> video clock speed; the limitations come from the monitor and driver
> limitations.
> 
> > Or should I shelve the card, an ATI X1650 and replace it with
> > something else that knows about 16x9 aspect ratios?
> 
> I will bet you a beer that your card is capable of driving your
> monitor resolution.
> 
According to Alex D. at xorg, no.  If the mode is not available in the vesa 
bios, and it isn't, every mode available is a 4x3 variant, so no twiddling 
with modelines will help.

The problem is that the vesa specs were carved in nice hard stone back in 
crt days, so all these widescreen monitors have never worked their way into 
the vesa bios, and likely never will.  The card of course is capable of the 
mode, but only when running the fglrx drivers.  The last time I tried that, 
I couldn't nuke it fast enough, the backplot was running 3-5 seconds behind 
the machine and I had to slow the base period to about a 3rd of what its 
doing now to stop the stalls.  Even then the motors were making very rough 
tones.

So, until I can find a 4x3 LCD monitor of about 19", I guess I run with 2" 
of blank screen on both sides, which gives me about a 14" equ monitor out 
of a 18.5".  Fortunately, the monitor has a mode button that switches that 
in about 1/2 second.




> 
> -- uberSVN's rich system and user administration capabilities and
> model configuration take the hassle out of deploying and managing
> Subversion and the tools developers use with it. Learn more about
> uberSVN and get a free download at: 
> http://p.sf.net/sfu/wandisco-dev2dev
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Nudists are people who wear one-button suits.

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Emc vs modern lcd monitors

[Przemek Klosowski]

On Tue, Aug 16, 2011 at 12:15 AM, gene heskett  wrote:
> On Tuesday, August 16, 2011 12:02:31 AM Przemek Klosowski did opine:
>
>> On Mon, Aug 15, 2011 at 6:06 PM, gene heskett  wrote:
>> > On Monday, August 15, 2011 05:15:23 PM Przemek Klosowski did opine:
>> >> Section "Monitor"
>> >>   Modeline "1360x768" 85.5 1360 1424 1536 1792 768 771 777 795
>> >> EndSection
>> >
>> > Many thanks, I just added that to the top of an extensive list in that
>> > machines xorg.conf, and I will go reboot it now for effects.
>> >
>> > I tried variations of 1360x768 and 1366x768.  The log contains a long
>> > list of available modes, which do not include either of those, and
>> > are uniformly within a pixel of a 4x3 aspect ratio.  Does that list
>> > of modes come from the card?  Or from the vesa driver?
>>
>> It's possible that your xorg.conf is messing you up---I bet you it's a
>> remnant of the old setup, and quite possibly not necessary. The long
>> list of modelines was how I learned to do X11 back in the days when we
>> had to whittle ones and zeros out of oak timbers but nowadays,
>> xorg.conf is just few lines long, and the Xorg server finds out the
>> video hardware, reads the monitor parameters over the video cable and
>> matches it to the built-in list of VESA standard modes. It'd be
>> interesting to try with a virgin minimalistic xorg.conf
>>
>> Section "Device"
>>       Identifier  "Videocard0"
>> EndSection
>>
>> Section "Screen"
>>       Identifier "Screen0"
>>       Device     "Videocard0"
>>       DefaultDepth     24
>> EndSection
>>
>> and maybe it'll figure something out on its own.  I don't know if
>> 1360x768 is on the VESA list so maybe you do need it after all.
>>
>> > The log says 136nx768 is not used because there is no mode of that
>> > name even though I have added it to the "Monitor" section.
>>
>> It has to match the "Monitor" section your Screen section is using;
>> there could be multiple Monitor sections
>> ("Monitor1","myOldCRT","LCDmonitor2", etc). Say something like
>>
>> Section "Screen"
>>       Identifier "Screen0"
>>       Device     "Videocard0"
>>         Monitor "MyMonitor"
>> ...
>> Section "Monitor"
>>   Identifier "MyMonitor"
>>   Modeline .
>> ...
>>
>> > If its the card, I wonder if it is flashable to add that mode?
>>
>> Nope, I doubt it, every VGA card is capable of any resolution from
>> like 320x320 (?) to 8000x8000 (???) within the memory capabilities and
>> video clock speed; the limitations come from the monitor and driver
>> limitations.
>>
>> > Or should I shelve the card, an ATI X1650 and replace it with
>> > something else that knows about 16x9 aspect ratios?
>>
>> I will bet you a beer that your card is capable of driving your
>> monitor resolution.
>>
> According to Alex D. at xorg, no.  If the mode is not available in the vesa
> bios, and it isn't, every mode available is a 4x3 variant, so no twiddling
> with modelines will help.

I think there's some sort of misunderstanding. The mode may be absent
in VESA table, but the video hardware is almost certainly capable of
producing it. Try the monitor/modeline I mentioned.
>
> The problem is that the vesa specs were carved in nice hard stone back in
> crt days, so all these widescreen monitors have never worked their way into

Yes, true, it's not in VESA---that's why we're not using VESA but
writing our own Modeline.

> the vesa bios, and likely never will.  The card of course is capable of the
> mode, but only when running the fglrx drivers.  The last time I tried that,

Nope, any video card made after 2000 or so can do this mode. You just
need to program the clock and shift registers to cycle at 13?? and 7??
basic video clocks---that's what the modeline tells teh server to do.

> I couldn't nuke it fast enough, the backplot was running 3-5 seconds behind
> the machine and I had to slow the base period to about a 3rd of what its
> doing now to stop the stalls.  Even then the motors were making very rough
> tones.

OK, performance might be an issue, but it's not related to the resolution!!
>

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users