KEJR

I have found that having a script PLC disable itself fails when using symbolic names. Please help, I was looking forward to never giving PLCs numbers ever again! example code that works as a one shot deal: open plc 1 send 1 "Starting Init PLC ...1" disable plc 1 close The following code executes continuously (rather nasty without a delay in there...) open plc InitPLC send 1 "Starting Init PLC ...1" disable plc InitPLC close Am I doing anything wrong, or is this a bug? KEJR

Hello, I just received an ELO touch monitor that I will be using on a machine. I haven't even gotten to the touchscreen driver yet, but the monitor is not displaying the gnome login correctly - it appears to be the wrong video mode or timing. The PowerPMAC works when I hook it up to another monitor, and the Elo monitor works attached to my desktop PC running windows. AM I going to have to edit Xorg.conf file, or should I try to configure something else? Any ideas to try? Here is my log file output: ************* /var/log/Xorg.0.log ************ X.Org X Server 1.4.2 Release Date: 11 June 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.2-10.lenny2) Current Operating System: Linux powerpmac 2.6.30.3 #12 Tue Nov 17 13:58:49 PST 2009 ppc Build Date: 11 June 2009 09:52:37AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec 31 16:02:28 1969 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Configured Monitor" (**) | |-->Device "Configured Video Device" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi (==) RgbPath set to "/etc/X11/rgb" (**) ModulePath set to "/usr/lib/xorg/modules,/usr/local/lib/xorg/modules" (==) |-->Input Device "Configured Mouse" (==) |-->Input Device "Generic Keyboard" (==) The core pointer device wasn't specified explicitly in the layout. Using the first core pointer device. (==) The core keyboard device wasn't specified explicitly in the layout. Using the first core keyboard device. (II) No APM support in BIOS or kernel (II) Loader magic: 0x101e350c (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 80:00:0: chip aaa1,bed1 card 0000,0000 rev 01 class 06,04,00 hdr 01 (II) PCI: End of PCI scan (II) PCI-to-PCI bridge: (II) Bus 129: bridge is at (128:0:0), (128,129,191), BCTRL: 0x0000 (VGA_EN is cleared) (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,0), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Host-to-PCI bridge: (II) Bus 128: bridge is at (0:0:0), (128,128,0), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 128 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 128 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 128 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX enabled (II) Loading extension GLX (II) LoadModule: "freetype" (II) Loading /usr/lib/xorg/modules//fonts/libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.4.2, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "record" (II) Loading /usr/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading extension XFree86-DRI (II) LoadModule: "displaylink" (II) Loading /usr/local/lib/xorg/modules/drivers//displaylink_drv.so (II) Module displaylink: vendor="X.Org Foundation" compiled for 1.4.2, module version = 0.0.1 ABI class: X.Org Video Driver, version 2.0 (II) LoadModule: "mouse" (II) Loading /usr/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.4.0.90, module version = 1.3.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) LoadModule: "kbd" (II) Loading /usr/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.4.0.90, module version = 1.3.1 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) DL: driver for : displaylink (II) Loading sub module "fbdevhw" (II) LoadModule: "fbdevhw" (II) Loading /usr/lib/xorg/modules/linux//libfbdevhw.so (II) Module fbdevhw: vendor="X.Org Foundation" compiled for 1.4.2, module version = 0.0.2 ABI class: X.Org Video Driver, version 2.0 (II) DL(0): using /dev/fb0 (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) DL(0): Manufacturer: ELO Model: 962 Serial#: 27404 (II) DL(0): Year: 2009 Week: 51 (II) DL(0): EDID Version: 1.3 (II) DL(0): Digital Display Input (II) DL(0): Max H-Image Size [cm]: horiz.: 30 vert.: 23 (II) DL(0): Gamma: 2.20 (II) DL(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) DL(0): First detailed timing is preferred mode (II) DL(0): redX: 0.595 redY: 0.350 greenX: 0.315 greenY: 0.575 (II) DL(0): blueX: 0.150 blueY: 0.125 whiteX: 0.300 whiteY: 0.320 (II) DL(0): Supported VESA Video Modes: (II) DL(0): 720x400@70Hz (II) DL(0): 640x480@60Hz (II) DL(0): 640x480@67Hz (II) DL(0): 640x480@72Hz (II) DL(0): 640x480@75Hz (II) DL(0): 800x600@56Hz (II) DL(0): 800x600@60Hz (II) DL(0): 800x600@72Hz (II) DL(0): 800x600@75Hz (II) DL(0): 832x624@75Hz (II) DL(0): 1024x768@60Hz (II) DL(0): 1024x768@70Hz (II) DL(0): 1024x768@75Hz (II) DL(0): Manufacturer's mask: 0 (II) DL(0): Supported Future Video Modes: (II) DL(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 (II) DL(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 (II) DL(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 (II) DL(0): Supported additional Video Mode: (II) DL(0): clock: 65.0 MHz Image Size: 0 x 0 mm (II) DL(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0 (II) DL(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0 (II) DL(0): Monitor name: ET1529L-8CWA (II) DL(0): Ranges: V min: 55 V max: 75 Hz, H min: 31 H max: 60 kHz, PixClock max 80 MHz (II) DL(0): (II) DL(0): EDID (in hex): (II) DL(0): 00ffffffffffff00158f62090c6b0000 (II) DL(0): 33130103801e1778ea6d8c9859509326 (II) DL(0): 204c52bfee00314f454f614f01010101 (II) DL(0): 01010101010164190040410026301888 (II) DL(0): 3600000000000018000000fc00455431 (II) DL(0): 3532394c2d384357410a000000fd0037 (II) DL(0): 4b1f3c080000000000000000000000fe (II) DL(0): 00200a0a0a0a0a0a0a0a0a0a0a0a003d (II) DL(0): Creating default Display subsection in Screen section "Default Screen" for depth/fbbpp 16/16 (==) DL(0): Depth 16, (==) framebuffer bpp 16 (==) DL(0): RGB weight 565 (==) DL(0): Default visual is TrueColor (==) DL(0): Using gamma correction (1.0, 1.0, 1.0) (II) DL(0): hardware: PPMAC Video DV (video memory: 2560kB) (**) DL(0): Option "fbdev" "/dev/fb0" (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) DL(0): Output PPMAC Video DV using monitor section Configured Monitor (II) DL(0): EDID vendor "ELO", prod id 2402 (II) DL(0): Using EDID range info for horizontal sync (II) DL(0): Using EDID range info for vertical refresh (II) DL(0): Printing DDC gathered Modelines: (II) DL(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) DL(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) DL(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) DL(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) DL(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) DL(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) DL(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) DL(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) DL(0): Modeline "1024x768"x0.0 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) DL(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) DL(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) DL(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) DL(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) DL(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) DL(0): Modeline "640x480"x74.8 30.75 640 664 728 816 480 483 487 504 -hsync +vsync (37.7 kHz) (II) DL(0): Modeline "800x600"x74.9 49.00 800 840 920 1040 600 603 607 629 -hsync +vsync (47.1 kHz) (II) DL(0): Modeline "1024x768"x74.9 82.00 1024 1088 1192 1360 768 771 775 805 -hsync +vsync (60.3 kHz) (II) DL(0): EDID vendor "ELO", prod id 2402 (II) DL(0): EDID vendor "ELO", prod id 2402 (II) DL(0): Using hsync ranges from config file (II) DL(0): Using vrefresh ranges from config file (II) DL(0): Printing DDC gathered Modelines: (II) DL(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) DL(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) DL(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) DL(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) DL(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) DL(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) DL(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) DL(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) DL(0): Modeline "1024x768"x0.0 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) DL(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) DL(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) DL(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) DL(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) DL(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) DL(0): Modeline "640x480"x74.8 30.75 640 664 728 816 480 483 487 504 -hsync +vsync (37.7 kHz) (II) DL(0): Modeline "800x600"x74.9 49.00 800 840 920 1040 600 603 607 629 -hsync +vsync (47.1 kHz) (II) DL(0): Modeline "1024x768"x74.9 82.00 1024 1088 1192 1360 768 771 775 805 -hsync +vsync (60.3 kHz) (II) DL(0): EDID vendor "ELO", prod id 2402 (II) DL(0): Output PPMAC Video DV connected (II) DL(0): Output PPMAC Video DV using initial mode 1024x768 (--) DL(0): Virtual size is 1024x768 (pitch 0) (**) DL(0): Driver mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz (II) DL(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (**) DL(0): Driver mode "1024x768": 82.0 MHz (scaled from 0.0 MHz), 60.3 kHz, 74.9 Hz (II) DL(0): Modeline "1024x768"x74.9 82.00 1024 1088 1192 1360 768 771 775 805 -hsync +vsync (60.3 kHz) (**) DL(0): Driver mode "1024x768": 78.8 MHz (scaled from 0.0 MHz), 60.1 kHz, 75.1 Hz (II) DL(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (**) DL(0): Driver mode "1024x768": 75.0 MHz (scaled from 0.0 MHz), 56.5 kHz, 70.1 Hz (II) DL(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (**) DL(0): Driver mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz (II) DL(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (**) DL(0): Driver mode "832x624": 57.3 MHz (scaled from 0.0 MHz), 49.7 kHz, 74.6 Hz (II) DL(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (**) DL(0): Driver mode "800x600": 50.0 MHz (scaled from 0.0 MHz), 48.1 kHz, 72.2 Hz (II) DL(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (**) DL(0): Driver mode "800x600": 49.5 MHz (scaled from 0.0 MHz), 46.9 kHz, 75.0 Hz (II) DL(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (**) DL(0): Driver mode "800x600": 49.0 MHz (scaled from 0.0 MHz), 47.1 kHz, 74.9 Hz (II) DL(0): Modeline "800x600"x74.9 49.00 800 840 920 1040 600 603 607 629 -hsync +vsync (47.1 kHz) (**) DL(0): Driver mode "800x600": 40.0 MHz (scaled from 0.0 MHz), 37.9 kHz, 60.3 Hz (II) DL(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (**) DL(0): Driver mode "800x600": 36.0 MHz (scaled from 0.0 MHz), 35.2 kHz, 56.2 Hz (II) DL(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (**) DL(0): Driver mode "640x480": 31.5 MHz (scaled from 0.0 MHz), 37.5 kHz, 75.0 Hz (II) DL(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (**) DL(0): Driver mode "640x480": 31.5 MHz (scaled from 0.0 MHz), 37.9 kHz, 72.8 Hz (II) DL(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (**) DL(0): Default mode "640x480": 31.5 MHz (scaled from 0.0 MHz), 37.9 kHz, 72.8 Hz (II) DL(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (**) DL(0): Default mode "640x480": 31.5 MHz (scaled from 0.0 MHz), 37.5 kHz, 75.0 Hz (II) DL(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (**) DL(0): Driver mode "640x480": 30.8 MHz (scaled from 0.0 MHz), 37.7 kHz, 74.8 Hz (II) DL(0): Modeline "640x480"x74.8 30.75 640 664 728 816 480 483 487 504 -hsync +vsync (37.7 kHz) (**) DL(0): Driver mode "640x480": 30.2 MHz (scaled from 0.0 MHz), 35.0 kHz, 66.7 Hz (II) DL(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (**) DL(0): Driver mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz, 60.0 Hz (II) DL(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (**) DL(0): Default mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz, 59.9 Hz (II) DL(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (**) DL(0): Driver mode "720x400": 28.3 MHz (scaled from 0.0 MHz), 31.5 kHz, 70.1 Hz (II) DL(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (**) DL(0): Display dimensions: (300, 230) mm (**) DL(0): DPI set to (86, 84) (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (==) DL(0): Backing store disabled (II) DL(0): DPMS enabled (II) DL(0): RandR 1.2 enabled, ignore the following RandR disabled message. (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension XAccessControlExtension (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (II) AIGLX: Screen 0 is not DRI capable (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/lib/xorg/modules/extensions//libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) GLX: Initialized MESA-PROXY GL provider for screen 0 (WW) Configured Mouse: No Device specified, looking for one... (II) Configured Mouse: Setting Device option to "/dev/input/mice" (--) Configured Mouse: Device: "/dev/input/mice" (==) Configured Mouse: Protocol: "Auto" (**) Option "CorePointer" (**) Configured Mouse: always reports core events (**) Option "Device" "/dev/input/mice" (==) Configured Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) Configured Mouse: ZAxisMapping: buttons 4 and 5 (**) Configured Mouse: Buttons: 9 (**) Configured Mouse: Sensitivity: 1 (**) Option "CoreKeyboard" (**) Generic Keyboard: always reports core events (**) Option "Protocol" "standard" (**) Generic Keyboard: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Generic Keyboard: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Generic Keyboard: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Generic Keyboard: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Generic Keyboard: CustomKeycodes disabled (II) evaluating device (Configured Mouse) (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) (II) evaluating device (Generic Keyboard) (II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD) (--) Configured Mouse: PnP-detected protocol: "ExplorerPS/2" (II) Configured Mouse: ps2EnableDataReporting: succeeded ************* end Xorg.0.log ***************

Hello, I'm planning on communicating to a RS-232 panel meter from within my custom C application. Are there any concerns with using the standard linux filesystem open/read/write calls from within a xenomai RTOS thread? I could have a non RTOS communications thread but it would be simpler and cleaner to embed the serial port query from within my main RTOS thread. Thank you, ~KEJR

Hello, We have purchased a video option PPMAC. I plugged in a monitor/keyboard/mouse yesterday and got to the graphical login screen just fine. When I logged in with a gnome session, however, it had failed since the /home folder is not writeable. This happened for both the "root" user as well as the "deltatau" user accounts. Doesn't it make sense to have the /home folders of each user be a separate partition? You could then leave it to the customer to mount it as read-only or read-write. As far as I can tell the /home folder is under the root partition as a part of /dev/sda2. I dont' feel comfortable mounting the root filesystem as read-write just for the desktop environment. In the long run we will probably end up installing a lightweight window manager and hijacking the bootup process somewhere so that we can auto-login a user account and start our HMI. In this case the fact that we don't have a writeable user account is not a huge concern. I'm fairly positive that some lightweight window managers don't need to write to your home folder every time they run (In fact TWM did work out of the box when I logged in). Thanks, ~KEJR

Hello, First off, I changed my PPMAC to 192.168.169.200 address using the IDE. This seemed to work and "/etc/network/interfaces" looks OK. I had been experiencing the telnet "delay" problem yesterday and have added my Windows PC's IP address to /etc/hosts file (which worked). It would seem from my internet search on this issue that the problem is with DNS doing a reverse lookup of the IP address and timing out. The fix of adding my PC address to "/etc/hosts" is somewhat temporary, however, in that our PCs use DHCP to obtain their IP addresses and it could change any day. Today if I change my PCs address (using static IP) to any address *not* listed in "/etc/hosts" telnet no longer works at all (I've waited several minutes and it just hangs). I have also noted that some file is being appended (or script generating) all of the addresses in subnet 192.168.0 to "/etc/hosts". At my company we are on the 192.168.169 subnet and it would seem I need to modify the script that is generating these addresses in "/etc/hosts". Is this something that should be done automatically upon changing your IP address in the IDE software (or script provided to do this from telnet)? I may just append all of the addresses in "192.168.169" subnet manually to "/etc/hosts" file, but something more automated would be nice if we ever have to change our PPMACs to another subnet some day. I did try to add entries in "/etc/hosts.allow" (again doing the remount,rw) but they don't seem to help. I tried the following: in.telnetd: ALL ALL: 192.168.169. None of these seems to work. Thanks, ~KEJR

Hello, Thank you so much for that example code. I know it will help me out alot and I'm sure it will to others. This is exactly the starting point I needed. Vive la Structures!!!! I am so glad not to deal with addresses! It is all so much more readable. :o) KEJR

We just got our Power PMAC CPU and I'll be playing around with it as time allows in the next month or two. I have a couple of MACRO cards (Acc-5E) as well as some Copley Accelnet MACRO drives. Since I have not even done MACRO in the turbo PMAC I really don't know where to start with the PowerPMAC. Is the setup basically the same except for the way I access the parameters? Is it possible to set up MACRO using data structures instead of hardcoded addresses (e.g. Gate[n].SomeParameter, etc)? Alternatively, does anyone have a quick start guide for MACRO on PowerPMAC? KEJR

Hello, Thank you for the detailed response. The extra space for gnome and related libraries makes alot of sense. It is somewhat becoming clear to me that we would be better off sticking with the Power PMAC "DisplayLink + 4GB flash" option so that we can minimize the dependencies on which display we use over the years on different machines. This is probably why you chose to develop this as an option as I can imagine supporting consumer grade devices with varying Displaylink chips to be a nightmare. The touchscreen appears to be a different beast, however. Elo and Microtouch don't seem to have a HDMI or DVI product in a display that is under 15" (their 12" is VGA DB15 only...). Most of our machines are small with meager display requirements so we have been forced to look at the "off brand" items such as the Lilliput. I've read alot of conflicting data regarding the lilliput touchscreens and chips (apparrently they use an egalax touch controller chip). Some people use the egalax HID driver built into kernel 2.6 and then just tweak their XF86 settings, while others say that you *need* to compile the kernel module from the manufacturer. Hopefully the lack of information means that the kernel driver works and people go with that. I guess we'll have to get a display and try it, at least they are cheap! Any advice on the touchscreen would be appreciated. Thank you, ~Ken

We have ordered two Power CPUs with video option, so we should have the video firmware already according to your last post. What is the difference in the firmware? Do you have different kernel modules precompiled, or is it just the setup of the X server? Maybe we need the extra flash? Is there anything preventing us from editing our own image ourselves (We will be tailoring it for our own customizations of linux anyway)? I have read alot of postings on the (oddly enough) MP3Car forums regarding the lilliput displays and their touchscreens. I don't know if they use the same touchscreen chip as the MIMO or not, but there are alot of posts discussing how to get it to work. It seems that one of the problems is that the touchscreen reports coordinates in absolute, where other HID units (like a mouse) report incremental information. Some other issues I've read about pertain to the fact that some chips mask themselves as storage device IDs initially so that driver software can be loaded automatically on systems like windows. Its the typical complexity you expect for trying to make things simpler! I may get one of these units to test as we don't need (or have room for) a 15" display on all of our machines. I'll post back if I get it working with the touchscreen. Thank you, ~Ken (KEJR)

I started a reply about the C api, but why not just use gpascii? I think that is what it is meant for and Telnet is really simple to use once you get past the login part (This isn't that bad either). I haven't done this myself (still waiting for my board to arrive) but I would go this route first if it were me. KEJR

Hello, Has anyone used a USB monitor interfaced to the "DisplayLink" chip on a Power PMAC? Monitors using this technology can be bought from companies such as Xenarc, Lilliput and Mimo. USB carries the video and touchscreen signals (I presume through an internal hub...). Most of the time these come with a generic HID touchscreen, so I'm more concerned if the video works with the Power PMAC. I was thinking of testing one but our CPUs are still on backorder. Thanks, KEJR

This goes somewhat beyond the scope of the Power PMAC, and may even extend back to the turbo PMAC, but is there anything in the Delta Tau servo algorithms that aid in tuning ballscrew systems with fairly high inertia mismatches? I'm sizing a ballscrew application (bellows coupling to a motor) for a very simple XY application and have inertia ratio (load / motor) of 6:1. In past experience with other motion controllers this is acceptable but going much more than a 5:1 ratio is usually ill advised for high performance tuning, even with notch filtering. Is this still the case with Power PMAC or are there any DT tricks to improve this? I apologize in advance if this is not the appropriate forum for this type of question. KEJR

Does this mean that if you want the program to automatically start up with the system that it will also automatically start when you download? What happens when the program is already running, does it restart the program with the new code? KEJR

Hello, Will the auto generated class be similar to the auto generated header file (when using C), in that the class members will contain P, Q, and M variable [i]indeces[/i] (which then get passed to SetGlobalVar(), etc)? Or will the class members actually contain the actual *[i]values[/i]* reported by the PPMAC? Either way it sounds like a nice option. I'm curious so that I can write our HMI library to accommodate different method overloads if we decide somewhen down the road to change to the PMAC server you described. Thank you, KEJR

Will the interpreter that matches the string to the PPMAC variable be able to handle differences in case (e.g. if you forgot to capitalize a letter, or vice versa)? This could mitigate some simple problems. I have to admit that I am somewhat concerned that a variable name spelling error will result in a runtime error (as opposed to a compile time error), but it is probably not as much of an issue for the HMI as it would be for the realtime machine control. Thank you, ~Ken

Hello, I am in the process of writing a C#/GTK# application for an HMI for the Power PMAC. It will run on the Power PMAC using the Mono runtime. I need to access PMAC Global variables defined in the IDE. Since the IDE is generating a C header file with the P variable names how do I access these from the C# language (since it doesn't have #include directives in the preprocessor like C/C++ does)? I would prefer not to use the command line interpreter to parse the variable name if possible for type checking reasons as well as efficiency. Thank you, KEJR

Thank you, Backing it up and/or cloning with Tar will suffice for now. In the future it will be great to point the IDE to an archive file and have it do a full filesystem restore. One thing that is essential for us is that the kernel and Debian system can be held static for a decent period of time. That is to say that we wouldn't want to upgrade our software every time a library changes for some minor feature we wouldn't use. I would imagine that at some point in time Delta Tau will upgrade to a future version of Debian, but it would be nice to keep our installations the same until some point of our choosing (within reason). So it sounds like by using the above approach, (or the IDE in the future) we can maintain our installations on a version that we decide and manage updates on our machines when we choose. If so, this is great. Thanks again, KEJR

Hello, I know that there are many programs that can create an image of the linux filesystem, and we are thinking of using that methodology for cloning Power PMAC CPU cards to some set standard when they come in from shipping. This would include a handful of software packages we install, modification to some init scripts, etc. This image might also be updated over the years as new linux programs are added, etc. Is this a valid approach? Should we include a backup/cloning of the boot block of NAND flash that contains the linux kernel? Alternatively does Delta Tau provide a backup/resore of the entire filesystem, including PMAC and linux software (including user changes to scripts, installed debian packages, etc). My concern is dealing with how a multitude of different machines will be administered over the years and how we will deal with complete system backups (including Non PMAC related stuff). If we could take a spare PPMAC cpu, image it with our customizations, and upload the machine specific files we would be happy in the event of a CPU problem. Thank you, KEJR

Is there a way to access the C API from C#? I'm thinking specifically that I would like to access the same functions as in C programs, such as the calls to get global vars and ptr vars. I realize that you can do this with GetResponse() but it is significantly slower. Is it simply a matter of finding the C api *.so file and doing the same as in this example?

I think we will probably just read/write a block of memory to/from a file in our Capp as you said, it is seeming simpler for what we want to do. I think I'll reserve a lower block of P vars (say, P0-P255 e.g.) to be saved/recalled and then we can use the IDE's builtin global variable naming mechanism to access these from either Capps,HMI,or scripts. Since we are writing our own C API anyhow I'll just add another set of function calls to save and recall these "static" P vars and call them on on power down / power up respectively. Thank you for the detailed response. KEJR

If I am interpreting your reply correctly we can do the following: - Add a command for each global variable to the "pp_save.tpl" file. - issue an online "save" command to save these variables. - Variables last saved values are loaded automatically at project startup. Is there a special command or other means of only saving the Global variables? I'm thinking of the scenario where you want to issue a "save" command on everything after downloading your project from the IDE, but not wanting to save the programs and parameters every time you want to save the "retentive" global variables. I prefer not to save the servo parameters once they might have been changed during runtime. That is to say I want to make sure that at power up the programs and setup parameters for the servos are exactly what they were when they were downloaded from the development environment. Thank you, KEJR

Hello, In many systems there is provision for special global variables that maintain their value after a power cycle. The best ones (in my opinion) use the global variable facility with a special type modifier in front of them, such as "Preserve", "NonVolatile" or something like that. Usually in application you are only maintaining a handful of counters and position values, but it may also involve things like boolean flags that store whether or not a part was loaded into a mechanism, etc for recovery code and what not. Is there anything like this built into the Power PMAC, or do we need to write a custom server for interfacing to files on the user flash? Thank you, KEJR

Brad, I can see how the Capp and script programs will send out data using the send command, but you did not describe the receiver function other than mention it is an AppWare. Is this Appware released yet, or is it part of the .net to PMAC communication package we have discussed that is in currently in development? Will the receiver function be able to process the buffer as raw data FIFO style stream (like a file or socket does)? On the HMI side I'd like to read the message in the buffer (terminated by an end of string character), and display it to a text box of some sort. Subsequent strings will *overwrite* previous entries in the text box instead of scrolling down. If I can read the "send" buffer as raw data in a FIFO buffer queue this is easy. Thank you, KEJR

Hello, We need a way to pass a single string (these can be finite size, e.g. 512 bytes max) from Capps to an HMI application. Ideally we might want the same functionality from motion progs and PLCs but this is not necessary at the moment. Since we aren't sure which path we are going to take for the HMI we want to leave the ability to access the string from the native PPMAC "C API" or any future API servers that are in development. We are currently considering packing the char array into the user buffer at a location picked by us because it is probably the most compatable with the different approaches. Is this the cleanest path to implement or is there a builtin facility for global string variables? Thank you, KEJR

Hello, Does the Power PMAC support MACRO currently? We are looking to use our first PPMAC application with MACRO and approx 8 axes of motion coupled to Copley Macro drives. Are there any issues using MACRO from a "C" language? Admittedly we won't be doing hardly any setup from the C language, especially if the IDE can handle it as a "wizard" or setup screen. We already own a Macro UMAC card with DSPGate 2B, is this compatable? Thanks, KEJR