Board index » delphi » Delphi components for industrial usage/controlling devices

2006-07-01 08:34:32 PM
delphi89
Has anybody used the Delphi components at www.opcconnect.com for real-time
work using Delphi, and if so, what do you think?
I find it quite interesting that the site claims Delphi is the best
development tool for real-time work.
--
Be the first one on your block to read the uproariously hilarious novel "the
Zany Time Travels of Warble McGorkle" (Book 2 in a trilogy). Download it
here: codecentral.borland.com/item.aspx
 

Blackbird Crow Raven writes:
and found very little.
I found only one major player that supports Delphi and no minor or
inexpensive ones.
I'd like to persure it but it looks rather bleak to me.
Can you provide a link where OpcConnect make that claim?
--
Jim Rowell
 

"Jim Rowell" <XXXX@XXXXX.COM>writes
--
Be the first one on your block to read the uproariously hilarious novel "the
Zany Time Travels of Warble McGorkle" (Book 2 in a trilogy). Download it
here: codecentral.borland.com/item.aspx
 

Jim Rowell writes:
semi-native Delphi code, I wrote my own.
Once you get the hang of it, their aproach is better IMO. I never
really liked the ODBC way --I mean OPC way-- and I dont remember
why anymore.
 

Blackbird Crow Raven writes:
high up-front fees and then substantial run-time fees. That just doesn't
suit a lot of what I do.
programs from various sources talk with each other but that is not real-time.
Real-time means that you have a deterministic system ie a system with
predictable timings.
I've pretty much given up on the idea. Secondary processor cards are
starting to make the most sense to me.
--
Jim Rowell
 

Blackbird Crow Raven writes:
equipment. You have to write your program using Opto's decidedly odd
language (but very powerful), compile it and download it onto the Opto
unit, which then runs virtually 'real-time' on the Opto-22 unit.
You can then control, monitor and communicate with your customised Opto
software, via a standard TCP socket (I use Indy V10.1 with no
problems), using a protocol of your own design. Works like a charm-
incredibly reliable, works off-line in case of PC failure and runs
pretty fast.
All of this means minimal distribution requirements (no OPC rubbish to
install) and precise control over the functionality of the Opto
controller.
I have been using Opto-22 for three years and have yet to have a
failure or a problem with the equipment- their stuff just works!
HTH!
Regards,
Keith Blows
 

"Keith Blows" <XXXX@XXXXX.COM>wrote in news:44a8d5b7
@newsgroups.borland.com:
I've figured out the product I am interested in is Optomux, but I can not even
find the product itself. Its pretty scattered.
Do you program the cards and then write a delphi program to interact with
that program? Can you point to somewhere that has a good description of the
process?
Thanks
Marc Pelletier
Goldak Airborne Surveys
 

Marc Pelletier writes:
please excuse any errors and omissions:
Yes, the product range has become pretty complicated. What you are
looking for is an Opto unit with an Opto 'brain'. This 'brain' allows
your custom Opto software to be run. You then add the necessary
RS-232/455 and digital/analogue modules to the 'brain' to complete the
controller rack. The range is vast, so you would need to speak to Opto,
for them to advise you on compatible modules. Once you have assembled
and configured the 'rack', you can begin writing your Opto software.
can program purely using diagrams, and/or using OptoScript. OptoScript
is very much like Visual Basic and quite comprehensive.
You design the software in Opto's IDE environment, compile it and then
download to the Opto brain, at which point it starts to run on the
controller. You can also go into an on-line debug mode, to debug your
code while it is running on the controller.
Once you have the basic functionality, there are a number of ways of
interacting with the controller (variables and sockets). Opto's socket
stuff is quite comprehensive (server sockets, client sockets, FTP,
etc.), although last I looked, not very well documented.
I have converted the Opto22 'C' socket SDK to Indy, if you are
interested, although I'd recommend the simple socket option, i.e.
where you create a client socket and talk directly to your OptoScript
code via TCP.
Getting into Opto takes a while, so be patient. Expect to spend 2-3
days getting used to configuring the units, i.e. defining I/O,
RS-232/455, I/O latches and the like. OptoScript is quite simple and
you should master that in a few days.
Regards,
Keith
 

"Keith Blows" <XXXX@XXXXX.COM>wrote in news:44ab8117
@newsgroups.borland.com:
done. Is the controller rack a standalone unit, or is it part of a pc? I
suspect it is standalone.
cheers
Marc
 

Marc Pelletier writes:
development IDE...
The Opto brain is a totally independent unit- think of the unit as an
ultra-reliable, solid state PC with real-time OS. It really only
requires a PC when you need to program it.
However, it can interact with other devices as mentioned above (via
RS-232/485, TCP, FTP, etc.), if you write the required code.
Regards,
Keith
 

I wrote a laser light show controler that runs in real time.
www.laser-light-show.com
It currently uses a processor card, but before the card it ran realtime under
windows. To give you an idea on how precise the realtime had to be, the program
had to move the laser beam at an exact rate point by point with no glitches
along the way. If there were glitches you would see bright dots where the
glitches caused small delays. I managed to have a smooth controled output.
It was hack programming, but it worked reliably as long as you did not try to
use other apps while the program was streaming points to the laser.
In order to get realtime, you have to turn off interupts using assembly code and
you have to read the keyboard through ports. One point you have to watch out
for is that interupts get turned back on when you read the keyboard, so you have
to turn them back off after a keyboard read.
Here is the unit, you will have to strip out what you need.
==================
unit HardwareInterface;
interface
uses
PCLCard, SysUtils, MPlayer, Windows;
const
// Keyboard values
ESC = 1;
kBack = 14;
kC = 46;
KCUp = 174;
kUp = 72;
kDown = 80;
kRight = 77;
kLeft = 75;
kNMinus = 74;
kNPlus = 78;
kI = 23;
kO = 24;
kLSkew = 51;
KRSkew = 52;
kF = 33;
kFUp = 161;
kS = 31;
kSUp = 159;
kL = 38;
kR = 19;
kU = 22;
kD = 32;
kH = 35;
kV = 47;
kX = 45;
kY = 21;
kZ = 44;
kSpace = 57;
kNuUp = 200; // N=NumberPad; u=Key up; Up=Up arrow
kNuRight = 205;
kNuDown = 208;
kNuLeft = 203;
kShiftD = 42;
kShiftU = 170;
kAltD = 56;
kAltU = 184;
kCtrlD = 29;
kCtrlU = 157;
F11_Up = 215;
k1 = 2; k2 = 3; k3 = 4; k4 = 5; k5 = 6; k6 = 7; k7 = 8; k8 = 9; k9 = 10; k0 =
11;
// FKeys
F1 = 59; F2 = 60; F3 = 61; F4 = 62; F5 = 63; F6 = 64; F7 = 65; F8 = 66;
F9 = 67; F10 = 68; F11 = 87; F12 = 88;
type
TMillisecond = LongWord;
TOptionKeys = set of (Ctrl, Alt, Shift);
THardware = class (TObject)
private
FBiosDateTime: TDateTime;
FCardTime: TMillisecond;
FInterupts: Boolean;
FKeyboard: Word;
FLastPCLCardTick: LongWord;
FMaxUpdateRate: TMillisecond;
FMediaPlayer: TMediaPlayer;
FOptionKeys: TOptionKeys;
FPCLCard: TPCLCard;
FPCLCardWrap: LongWord;
procedure SetInterupts(const Value: Boolean);
procedure SetMaxUpdateRate(const Value: TMillisecond);
procedure SetPCLCard(const Value: TPCLCard);
protected
function BiosTime: TDateTime;
public
constructor Create;
destructor Destroy; override;
procedure Update;
property BiosDateTime: TDateTime read FBiosDateTime;
property CardTime: TMillisecond read FCardTime;
property Interupts: Boolean read FInterupts write SetInterupts;
property Keyboard: Word read FKeyboard;
property MaxUpdateRate: TMillisecond read FMaxUpdateRate write
SetMaxUpdateRate;
property MediaPlayer: TMediaPlayer read FMediaPlayer write FMediaPlayer;
property OptionKeys: TOptionKeys read FOptionKeys;
property PCLCard: TPCLCard read FPCLCard write SetPCLCard;
end;
function Hardware: THardware;
implementation
var
ImpHardware: THardware = nil;
function Hardware: THardware;
begin
if ImpHardware = nil then
ImpHardware:= THardware.Create;
Result:= ImpHardware;
end;
{ THardware }
{
********************************** THardware ***********************************
}
constructor THardware.Create;
begin
inherited Create;
FPCLCard:= TPCLCard.Create;
FInterupts:= True;
FMaxUpdateRate:= 25;
end;
destructor THardware.Destroy;
begin
Interupts:= True;
SetPCLCard(nil);
inherited Destroy;
end;
function THardware.BiosTime: TDateTime;
var
H, M, S: Byte;
function BCD(I: Byte): Byte;
var
ten, one: Byte;
begin
{Return a binary number given a BCD number}
{high nible is tens and lower nible is ones}
ten:= I and $F0;
ten:= ten shr 4;
one:= I and $0F;
Result:= ten*10+one;
end;
begin
{get info from realtime clock using Bios Int $1a function 2}
asm
MOV AH, 2
INT $1A
MOV S, DH
MOV M, CL
MOV H, CH
end;
{Convert the returned BCD to normal binary}
H:= BCD(H);
M:= BCD(M);
S:= BCD(S);
Result:= Date+EncodeTime(H, M, S, 0);
end;
procedure THardware.SetInterupts(const Value: Boolean);
var
M: TMsg;
begin
if Value=FInterupts then Exit;
FInterupts:= Value;
if Value then
begin
asm
STI
end;
{ Remove Keyboard buffering }
PeekMessage(M, 0, 0, 0, PM_NOYIELD or PM_REMOVE);
end
else
asm
CLI
end;
end;
procedure THardware.SetMaxUpdateRate(const Value: TMillisecond);
begin
FMaxUpdateRate := Value;
end;
procedure THardware.SetPCLCard(const Value: TPCLCard);
begin
if Value=FPCLCard then Exit;
FPCLCard.Free;
FPCLCard := Value;
end;
procedure THardware.Update;
var
PCLCardTick: LongWord;
PCLCardMS: LongWord;
CardMSPerWrap: LongWord;
Kbd: Word;
M: TMsg;
begin
// Read PCLCard time and update CardTime
PCLCardTick:= PCLCard.GetTimer;
if PCLCardTick < FLastPCLCardTick then
begin
// re-check to make sure there is not an error
PCLCardTick:= PCLCard.GetTimer;
if PCLCardTick < FLastPCLCardTick then
FPCLCardWrap:= FPCLCardWrap+1;
end;
FLastPCLCardTick:= PCLCardTick;
PCLCardMS:= PCLCardTick div (PCLCard.TimerTicksPerSecond div 1000);
// Handle clock wrapping
CardMSPerWrap:= High(LongWord) div (PCLCard.TimerTicksPerSecond div 1000);
PCLCardMS:= PCLCardMS+CardMSPerWrap*FPCLCardWrap;
// Do updates if proper amount of time has elapsed
if (PCLCardMS-CardTime)>= MaxUpdateRate then
begin
{ Reduce errors when reading the keyboard }
asm
STI
end;
{ Remove Keyboard buffering }
PeekMessage(M, 0, 0, 0, PM_NOYIELD or PM_REMOVE);
FCardTime:= PCLCardMS;
FBiosDateTime:= BiosTime;
// Read keyboard
asm
PUSH EAX
MOV DX, $60
IN AL, DX
XOR DX, DX
MOV DL, AL
POP EAX
MOV Kbd, DX
end;
// Reset interupts if off
if not Interupts then
asm
CLI
end;
FKeyboard:= Kbd;
// Update OptionKeys
case Kbd of
kCtrlD: FOptionKeys:= FOptionKeys + [Ctrl];
kShiftD: FOptionKeys:= FOptionKeys + [Shift];
kAltD: FOptionKeys:= FOptionKeys + [Alt];
kCtrlU: FOptionKeys:= FOptionKeys - [Ctrl];
kShiftU: FOptionKeys:= FOptionKeys - [Shift];
kAltU: FOptionKeys:= FOptionKeys - [Alt];
end;
end;
end;
initialization
finalization
ImpHardware.Free;
end.
===================
"Blackbird Crow Raven" <XXXX@XXXXX.COM>writes

William Egge writes:
accessing app.
Was this application only used on Win95/98?
I ask this, for I also use STI / CLI (in order to get realtime
recording) for my Hardware oscilloscope cotroller program:
www.gu.edu.au/school/eng/mmt/HSpace.html
But I had found STI / CLI only worked for Win95/98, NOT for NT (2K,XP).
So did you get the code to work for NT?
--
Charles Hacker
Lecturer in Electronics and Computing
School of Engineering
Griffith University - Gold Coast
Australia
 

I "beleive" it did work under XP, its been a while. I remember developing on
a machine that would boot into XP or Win98 but I cannot remember if I ran
the old routine under XP - I seem to remember that I did and it worked,
maybe better than Win98 because I could totaly freeze XP and have to turn
off the power in order to reboot.
I don't have time to test it, but you can test it by removing the PCLCard
code then create an instance of the THardware class (or call the Hardware
function for a global instance) then set the interupts property to true and
see if your mouse freezes.
Hardware.Interupts:= False;
Sleep(5000);
Hardware.Interupts:= True;
-Bill
"Charles Hacker" <XXXX@XXXXX.COM>writes