View unanswered posts | View active topics It is currently Fri May 24, 2013 11:33 am



Reply to topic  [ 10 posts ] 
 osasubr hogging the cpu 
Author Message

Joined: Feb 09, 2009
Posts: 108
Post osasubr hogging the cpu
I have upgraded my Indigo mac from a G4 Cube (Tiger) to a G4 Mac Mini (Leopard). Indigo and Serial Bridge have been installed, and the database and scripts have been copied over.

I just got around to plugging in my Xbee Explorer, which uses an FTDI USB-Serial chip. I installed the FTDI drivers, plugged in the Xbee Explorer, and it shoes up in the Serial Port selector in Serial Bridge. With it selected and the baud rate/etc selected, it sends and receives data just fine.

However, a process called "osasubr" takes up from 35% to 70% of the cpu while it is running. It happens when I change the Serial Port selector from _Offline_ to my device. It stops when I take it back _Offline_.

I have no idea where to start troubleshooting, so any help would be great. Is this a Leopard thing? A forum search turned up some osasubr posts, but I didn't see this problem.

Thanks,
Brian


Thu Jul 29, 2010 10:58 pm
Profile
Site Admin
User avatar

Joined: Jan 27, 2003
Posts: 11698
Location: Texas
Post Re: osasubr hogging the cpu
Hi Brian,

osasubr is the name of the process that is running the AppleScript started by SerialBridge. Depending on what that script is doing, it can use anywhere from negligible CPU time to nearly 100%. You want to make sure you don't have any tight busy loops that are running continuously. The SerialBridge calls that wait for data use almost no CPU time if there is no serial data available.

_________________
Image


Thu Jul 29, 2010 11:05 pm
Profile WWW

Joined: Feb 09, 2009
Posts: 108
Post Re: osasubr hogging the cpu
Swapped in the default script and that fixed it. I guess I got too clever with my Applescript.

Thanks.


Mon Aug 02, 2010 1:32 pm
Profile

Joined: Mar 31, 2008
Posts: 739
Post Re: osasubr hogging the cpu
I also have this problem, but in my case it was hogging memory, using over 800 megs. I'm running only two SB scripts, both of which are pretty simple. Could you take a sec to glance at these scripts and see if there is anything obvious?

Thanks!
Code: Select all
-- Sample connection attachment script for Serial Bridge.
--
-- This script, if it is in the same folder as the Serial Bridge database settings
-- file (it is by default), will automatically be loaded and launched when Serial
-- Bridge is launched. It will be terminated and reloaded whenever any serial
-- port settings change for this connection, or if the Reload button is pressed.
--
-- MyProcessSerialData() below contains sample code you can modify to
-- wait for serial data, read serial data, send serial data, and log information
-- to the Serial Bridge log window.
--
-- The entry point into this file is startCommunication(). Although
-- documentation is provided below for both functions; you will probably
-- only need to modify MyProcessSerialData().
--
-- 2005-03-29 Original. (Matt Bendiksen)
-- 2005-04-01 Fixed event timeout bugs. (Matt Bendiksen)

-----------
--

(*
    --Serial process script for Serial Bridge
    --by M. Bendikson
    --mods by dtich
    --mods by HFTobeason
  --mods by hamw   for Ademco

    --This script reads Hex message data broadcast from an Ademco Vista 128 and logs the parsed value to IndigoServer, repeating until fatal error. The script was initially used to parse the DTC serial board.
    *)
property commandString : ""
property commandCodes : {"10071 House Disarmed", "01071 House Armed Away", "00171 House Armed Stay", "10070 Garage Disarmed", "01070 Garage Armed Away", "0207233 Window MBR Front", "0760965 Window MBR Back", "0781073 Office Window Game Rm", "0612867 Emily Window Game Rm"}

on MyProcessSerialData(connectionName)
   tell application "Serial Bridge"
      -- this will block until at least 1 byte is available
      wait for data from source connectionName
      set byteRead to read byte from source connectionName
      if byteRead is 13 or byteRead is 10 then -- CR=Hex 0D=ASCII 13 / LF=Hex 0A=ASCII 10
         if commandString is not "" then
            log "trying to parse commandString: " & commandString
            if length of commandString < 5 then
               log "commandString length too short to parse"
            else
               if length of commandString is 94 then
                  set nameofstate to (characters 2 through 4 of commandString as string)
                  set nameofpartition to (characters 30 through 31 of commandString as string)
                  set commandData to (characters 62 through -1 of commandString as string)
                  
                  set commandDescription to my MyParse(nameofstate & nameofpartition)
                  if commandDescription is not "" then
                     log "commandString found matching code; setting Indigo variable value"
                     tell application "IndigoServer"
                        if commandDescription contains "House" then
                           set value of variable "AlarmHouseState" to commandDescription
                           set value of variable "AlarmHouseDisplay" to commandData
                        else
                           set value of variable "AlarmGarageState" to commandDescription
                           set value of variable "AlarmGarageDisplay" to commandData
                        end if
                        
                        if commandDescription contains "House Disarmed" then
                           set value of variable "AlarmHouseStateDisplay" to "Alarm OFF"
                        end if
                        
                        if commandDescription contains "House Armed Away" then
                           set value of variable "AlarmHouseStateDisplay" to "Armed Away"
                        end if
                        
                        if commandDescription contains "House Armed Stay" then
                           set value of variable "AlarmHouseStateDisplay" to "Armed Stay"
                        end if
                        
                        if commandDescription contains "House Armed Instant" then
                           set value of variable "AlarmHouseStateDisplay" to "Armed Instant"
                        end if
                        
                     end tell
                  end if
               else
                  if length of commandString is 15 then
                     set nameofsensor to (characters 6 through 12 of commandString as string)
                     set AlarmSensorRawData to (characters 1 through 15 of commandString as string)
                     --tell application "IndigoServer"
                     --set value of variable "AlarmSensorRawData" to AlarmSensorRawData
                     --log AlarmSensorRawData
                     --end tell
                     set commandDescription to my MyParse(nameofsensor)
                     if commandDescription is not "" then
                        log "commandString found matching code; setting Indigo variable value"
                        tell application "IndigoServer"
                           set value of variable "AlarmSensor" to commandDescription
                           --log AlarmSensor
                        end tell
                     end if
                  end if
                  
                  log "commandString no matching code found"
               end if
            end if
            set commandString to ""
         end if
      else
         set charRead to ASCII character byteRead
         set commandString to commandString & charRead
      end if
   end tell
end MyProcessSerialData

on startCommunication(connectionName)
   tell application "Serial Bridge"
      try
         set bufferDumpStr to (read string from source connectionName)
         log "dumping rs232 buffer: " & bufferDumpStr
      end try
      -- Loop forever: wait for data, read it, process it, and optionally send
      -- out serial data.
      --
      -- We do not want our script to return or exit since Serial Bridge
      -- only calls our script on launch (or when the Reload Script button
      -- is pressed).
      repeat while true
         try
            set maxTimeoutDelay to 8947848 -- 103.56 days (hex 0x00888888)
            with timeout of maxTimeoutDelay seconds
               my MyProcessSerialData(connectionName)
            end timeout
         on error number errNum
            if errNum is -1712 then
               log "timeout waiting for serial data" using type "Error"
            else if errNum is -1708 then
               log "AppleEvent not handled" using type "Error"
               --return -- fatal error; exit script processing
            else if errNum is -128 then
               log "connection script aborted" using type "Error"
               return -- fatal error; exit script processing
            else
               log "error " & errNum & " inside MyProcessSerialData()" using type "Error"
               --return -- maybe fatal error; exit script processing
            end if
         end try
      end repeat
   end tell
end startCommunication

on MyParse(commandString)
   repeat with x from 1 to count of commandCodes
      if word 1 of item x of commandCodes is commandString then
         return (characters 7 through -1 of item x of commandCodes as string)
      end if
   end repeat
   return ""
end MyParse
(* The above read verbs all have an optional argument, "timeout after",
                     * to specify how long to wait in milliseconds for the data if it is not
                     * currently available. If no timeout argument is present, then a
                     * timeout error will be immediately thrown if there is not enough
                     * data present to fulfill the request.
                     *)

-----------------------------------------------------------------------------
(* To send data use the "send to source" verb. You can either send
                     * a single byte, multiple bytes as a list, or a string. To send a single byte:
                     *)

-----------
-- Serial Bridge will call the startCommunication() subroutine after it has opened
-- the serial port connection for this connection. It is only called after the serial
-- port connection has been opened, shortly after Serial Bridge launches or if
-- the user presses the Reload Script button.
--
-- The argument, connectionName, is a string used to identify this serial port
-- connection, and will always be the folder name in which this script (and
-- database settings file) resides. This value should be passed to all read, write,
-- and wait serial functions to identify which serial port connection the script is
-- using.
--



Code: Select all
-- Sample connection attachment script for Serial Bridge.
--
-- This script, if it is in the same folder as the Serial Bridge database settings
-- file (it is by default), will automatically be loaded and launched when Serial
-- Bridge is launched. It will be terminated and reloaded whenever any serial
-- port settings change for this connection, or if the Reload button is pressed.
--
-- MyProcessSerialData() below contains sample code you can modify to
-- wait for serial data, read serial data, send serial data, and log information
-- to the Serial Bridge log window.
--
-- The entry point into this file is startCommunication(). Although
-- documentation is provided below for both functions; you will probably
-- only need to modify MyProcessSerialData().
--
-- 2005-03-29 Original. (Matt Bendiksen)
-- 2005-04-01 Fixed event timeout bugs. (Matt Bendiksen)

-----------
--
on MyProcessSerialData(connectionName)
   tell application "Serial Bridge"
      -----------------------------------------------------------------------------
      (* "wait for data" will block our script until serial data become
             * available to read. Note it has optional argument to specify
             * the number of bytes to wait for ("to count") and the maximum
             * amount of time to wait in milliseconds until a timeout error is
             * thrown ("timeout after").
             *)
      wait for data from source connectionName to count 25
      
      (* Now that 25 bytes of data are available to read, we can extract out a single byte:
             *)
      (*set singleByte to read byte from source connectionName
      log "one byte = " & (singleByte as integer) using type "Sample"
      
      (* or multiple bytes:
             *)
      set threeBytes to read byte list from source connectionName to count 3
      log "first byte = " & item 1 of threeBytes using type "Sample"
      log "second byte = " & item 2 of threeBytes using type "Sample"
      log "third byte = " & item 3 of threeBytes using type "Sample"
      
      (* or a string of 5 characters:
             *)
      set fiveCharString to read string from source connectionName to count 5
      log "five character string = " & fiveCharString using type "Sample"
      *)
      
      (* or a string of all the available characters:
             *)
      set restOfString to read string from source connectionName
      --log "rest of string = " & restOfString using type "Sample"
      log "Vaux Output = " & restOfString using type "Sample"
      tell application "IndigoServer"
         if restOfString contains "!" then
            set value of variable "vauxResponse" to restOfString
         end if
      end tell
      
      (* The above read verbs all have an optional argument, "timeout after",
             * to specify how long to wait in milliseconds for the data if it is not
             * currently available. If no timeout argument is present, then a
             * timeout error will be immediately thrown if there is not enough
             * data present to fulfill the request.
             *)
      
      -----------------------------------------------------------------------------
      (* To send data use the "send to source" verb. You can either send
             * a single byte, multiple bytes as a list, or a string. To send a single byte:
             *)
      (*send to source connectionName byte 127
      
      (* or to send multiple bytes:
             *)
      send to source connectionName byte list {2, 4, 8, 16, 32, 64}
      
      (* or to send a character string:
             *)
      send to source connectionName string "hello world"
      *)
   end tell
end MyProcessSerialData

-----------
-- Serial Bridge will call the startCommunication() subroutine after it has opened
-- the serial port connection for this connection. It is only called after the serial
-- port connection has been opened, shortly after Serial Bridge launches or if
-- the user presses the Reload Script button.
--
-- The argument, connectionName, is a string used to identify this serial port
-- connection, and will always be the folder name in which this script (and
-- database settings file) resides. This value should be passed to all read, write,
-- and wait serial functions to identify which serial port connection the script is
-- using.
--
on startCommunication(connectionName)
   tell application "Serial Bridge"
      -- Loop forever: wait for data, read it, process it, and optionally send
      -- out serial data.
      --
      -- We do not want our script to return or exit since Serial Bridge
      -- only calls our script on launch (or when the Reload Script button
      -- is pressed).
      repeat while true
         try
            set maxTimeoutDelay to 8947848 -- 103.56 days (hex 0x00888888)
            with timeout of maxTimeoutDelay seconds
               my MyProcessSerialData(connectionName)
            end timeout
         on error number errNum
            (* Log timeout errors (-1712) but continue processing loop. Without
             * handling this error, the script would throw out of the repeat loop
             * and terminate if any of the script calls were to throw a timeout error.
             * Normally, if there was a timeout error thrown you would want
             * to continue processing your main loop in an attempt to get back
             * in syncronization with the hardware. By catching this error we
             * will do exactly this and continue to process our script repeat loop.
             *)
            if errNum is -1712 then
               log "timeout waiting for serial data" using type "Error"
            else if errNum is -1708 then
               log "AppleEvent not handled" using type "Error"
               return -- fatal error; exit script processing
            else if errNum is -128 then
               log "connection script aborted" using type "Error"
               return -- fatal error; exit script processing
            else
               log "error " & errNum & " inside MyProcessSerialData()" using type "Error"
               return -- maybe fatal error; exit script processing
            end if
         end try
      end repeat
   end tell
end startCommunication


Thu Mar 31, 2011 8:16 pm
Profile
Site Admin
User avatar

Joined: Jan 27, 2003
Posts: 11698
Location: Texas
Post Re: osasubr hogging the cpu
I'm not seeing anything wrong with the scripts.

Is it the osasubr process or SerialBridge process that is using 800+ megs? How big are the log files that are being generated? Does closing the Log Window in SB and then restarting SB (keeping the window closed) help keep memory usage down?

_________________
Image


Sat Apr 02, 2011 9:57 am
Profile WWW

Joined: Mar 31, 2008
Posts: 739
Post Re: osasubr hogging the cpu
Did what you said, e.g. turned off the log window and restarted SB. Still with creeping memory usage as shown below. Started off at 170 this AM, now up to 266. On the plus side, the accumulating settings files do seem to stop if one quits and restarts SB following a reboot of the computer.


Attachments:
SB Memory Use.tiff
SB Memory Use.tiff [ 231.75 KiB | Viewed 1270 times ]
Sun Apr 03, 2011 9:05 am
Profile

Joined: Mar 31, 2008
Posts: 739
Post Re: osasubr hogging the cpu
At 8:30 PM. Have restarted SB and will observe.


Attachments:
SB Mem 20110403 pm.tiff
SB Mem 20110403 pm.tiff [ 82.58 KiB | Viewed 1157 times ]
Sun Apr 03, 2011 6:37 pm
Profile

Joined: Mar 31, 2008
Posts: 739
Post Re: osasubr hogging the cpu
This is the log file folder. None seem too big to me.


Attachments:
SB Mem Log File 20110403 pm.tiff
SB Mem Log File 20110403 pm.tiff [ 188.28 KiB | Viewed 1157 times ]
Sun Apr 03, 2011 6:42 pm
Profile

Joined: Mar 31, 2008
Posts: 739
Post Re: osasubr hogging the cpu
Pending any further ideas I set up a time-date action to quit, restart and hide SB every 8 hours. Should at least work around the problem if not solve it.


Fri Apr 08, 2011 9:11 pm
Profile
Site Admin
User avatar

Joined: Jan 27, 2003
Posts: 11698
Location: Texas
Post Re: osasubr hogging the cpu
One last thought: have you checked to make sure you have the latest version of the USB to serial driver you are using? The quit/restart of SB will probably work around the problem, but I do wish I knew where the memory leak was originating.

_________________
Image


Mon Apr 11, 2011 7:54 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 10 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.   Template designed by STSoftware.