Alaska Software Inc. - Michael's Xbase++ OOP Survival Manual, Part III
Username: Password:
AuthorTopic: Michael's Xbase++ OOP Survival Manual, Part III
Michael HoffmannMichael's Xbase++ OOP Survival Manual, Part III
on Sun, 02 Nov 2008 12:10:31 +0100
Hello fellow developers,

I just updated the Cockpit site (News and Future Events sections) and added some information on what I'll be speaking about in my 
presentation at the Xbase++ Party in three weeks in Holland. See www.xcockpit.com.

Best regards,

Michael
Osvaldo Ramirez Re: Michael's Xbase++ OOP Survival Manual, Part III
on Mon, 03 Nov 2008 21:07:38 -0700
Heloo Michael Hoffmann

Please, tell me more about "Tom" device.

I would like to know, what kind of app are running that use this device.
and how it is connected to Cockpit lib.

Good luck in Holland, I would like to be there, but the economy word is 
down, anyway ... see you sooner or later.

Best Regads
Osvaldo Ramirez
Michael HoffmannRe: Michael's Xbase++ OOP Survival Manual, Part III
on Thu, 06 Nov 2008 19:22:48 +0100
Hello Osvaldo,

>
> Please, tell me more about "Tom" device.
>
> I would like to know, what kind of app are running that use this device.
> and how it is connected to Cockpit lib.

Currently we have two applications that use the Tom device.

The first application monitors a production line. It is attached to a machine which sends impulses about the state of the machine 
(stopped, running, automatic mode) and an impulse whenever one product was finished (in fact it can be more complex). The 
application then calculates the production speed, compares it to a speed that should be maintained, warns the operator if he is 
producing too slowly. It also forces the machine operator to enter a cause if production is stoppend for longer than a given 
interval. Futhermore the addition of new raw material(s) is monitored and lot numbers are recorded. In addition, this application is 
controlling an ink jet printing device that marks every piece produced with the machine ID, a time stamp and the product description 
text. In this case Tom is connected to the machine controlling electronics using 24V lines. Of course this application also records 
the operator, who will soon be able to identify himself with his transponder. All this happens in a bigger production planning 
system which is also connecet to a backend SAP system.

The other application was written for an "office of public health" (Gesundheitsamt). It controls the "Sagabude" a device very 
similar to those booths that can be found at fun fairs where you have to throw balls at things to win something. The Sagabude has 12 
panels you can hit with balls you throw. Depending on the configuration loaded into the device you must hit only correct panels. For 
example, you must mix a cocktail only with non-alcolholic ingredients. So it's OK to hit banana juice, but hitting whisky will blow 
you out of the game. During the game the device instructs you what you have to do (spoken text), if you are doing fine or not and it 
tells you when you've lost and won. The device is also equipped with different kinds of light effects controlled by our software 
through the Tom device. There are different configurations that can be loaded for different topics: Information on Aids infection 
ways, Contraceptive methods, alcohol prevention, ... This device is big fun and attracted many viewers while I tested it in my 
garage. And, to be honest, it hurts when it calls you a loser because you always miss the panels....

Cockpit is required for the communication between the Tom device and the PC running the controlling software. In fact it's a serial 
connection over a USB device and we're using the standard O/S calls for configuration and I/O.

Further down I attach the Tom class declaration in case your're intereted in more details.

>
> Good luck in Holland, I would like to be there, but the economy word is down, anyway ... see you sooner or later.

Thanks. I'm looking forward to seeing you again, soon!

Best regards,

Michael


--- snip ---

SECTION CLASS Tom

   *****************************************************************************
                                  The Tom Class                               
   *****************************************************************************

   CLASS Tom

    EXPORTED:

       Serial COM port for communication with Tom
      VAR comPort

      VAR commandTimeout

       Inport state
      VAR inPortBits    && 16 bits (0..15)

      * Outport state
      VAR outPortBits    && 9 bits (0..8)

       The thread taking care of all incoming messages
      VAR listenerThread

       The event queue
      VAR eventQueue

      * The reply to an external request
      VAR replyType   && "Semaphore" variable, when it's # NIL, a reply was received,
                      && ::replyInfo must set before setting ::replyType
      VAR replyInfo   && Set before setting replyType

       control of the listener thread
      VAR stopListener

      VAR notificationSinks

       A block to be executed in the listener thread when an event occurs
      VAR eventFilterBlock

      * Array of 16 numeric elements, 1 for each inport bit, or NIL
      VAR inCounters

       The object handling transponder events
      VAR transponderHandler


     EXPORTED:
      CLASS METHOD Connect
      SYNC METHOD Disconnect
      SYNC METHOD SetOutBit
      SYNC METHOD GetEvent
      SYNC METHOD GetTicks
      SYNC METHOD GetInState
      SYNC METHOD GetInBit
      SYNC METHOD GetOutBit

      METHOD Init
      METHOD SendMessage
      METHOD ReceiveMessage
      SYNC METHOD Command

      METHOD Reply     && HIDDEN

      * These methods use :Command() and hence don't need the SYNC attribute
      METHOD SetRoleString
      METHOD GetRoleString
      METHOD Squawk
      METHOD SetHardwareInBitMask
      METHOD SetHardwareOutBitMask

       Using SYNC here is not necessary
      METHOD GetInCounter
      METHOD SetInCounter

      SYNC METHOD RegisterNotificationSink
      SYNC METHOD DeregisterNotificationSink

      METHOD ConnectTomRfDevice


     HIDDEN:

      CLASS METHOD FindDevicePort
      METHOD ReadACharOrWaitALittle
      METHOD Listener

      INLINE METHOD EventsWaiting
      RETURN .NOT. ::eventQueue:Empty()

      METHOD SetEventFilterBlock

   ENDCLASS


--- snap ---
Osvaldo Ramirez Re: Michael's Xbase++ OOP Survival Manual, Part III
on Thu, 06 Nov 2008 20:10:31 -0700
Michael Hoffmann wrote:

> 
> Thanks. I'm looking forward to seeing you again, soon!
> 

I hope to ...


Some times is good to see others areas like communications device.

Well, a client of mine, want to control cash register via HTTP, so far 
so good, So a friend of mine, are designer a electronic board to control 
an 'servomotor' using this Web server ADAM-6052, this kind of device has 
inside an web server that are controled all pins.

http://www.advantech.com/products/16-ch-Source-type-Isolated-Digital-I-O-Module/mod_1-2MLEAP.aspx

So, We can open, close, know some status or send a pulse over some ping 
via remote using http or tcp.

If you has time, let me know your point of view about adam-6502

Thas was the reason because I asked you.

Thanks a lot and Best Regards
Osvaldo Ramirez
Michael HoffmannRe: Michael's Xbase++ OOP Survival Manual, Part III
on Fri, 07 Nov 2008 07:43:06 +0100
Hello Osvaldo,

before developing Tom we checked out the devices on the market if they fitted our needs. One of them was a similar Advantech I/O 
device and it even made it into some of our productive software. Their devices seem to be well manufactured and so far we didn't 
have any trouble with it. Unfortunatly it was not the ultimate solution for us because it does not have an event queue (which the 
sales guy told us it should have) with time stamped events. So, when your computer has some of its "silent moments" (blocked for 
some seconds due to some network I/O), your software wouldn't be able to even pick up changes on the I/O ports. Tom buffers all 
events.

For your problem the Adam-6052 should work perfectly, however I must admit that opening and closing a cash register via TCP/IP over 
a network is a bit of overkill and might even become a security leak. The controllable cash registers I have seen so far are spring 
loaded and the software just releases a drawer lock which allows the spring to push the drawer open. This lock release action seems 
to be triggered by a signal change on one pin of a serial port. That should be a lot cheaper than the Adam 6052 + electronics to 
control a servo motor.

Best regards,

Michael

------------------------------
www.xcockpit.com
------------------------------