|
Page 1 of 1
|
[ 10 posts ] |
|
| Author |
Message |
|
kd5crs11
Joined: Feb 09, 2009 Posts: 108
|
 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 |
|
 |
|
matt (support)
Site Admin
Joined: Jan 27, 2003 Posts: 11698 Location: Texas
|
 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.
_________________
|
| Thu Jul 29, 2010 11:05 pm |
|
 |
|
kd5crs11
Joined: Feb 09, 2009 Posts: 108
|
 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 |
|
 |
|
hamw
Joined: Mar 31, 2008 Posts: 739
|
 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 |
|
 |
|
matt (support)
Site Admin
Joined: Jan 27, 2003 Posts: 11698 Location: Texas
|
 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?
_________________
|
| Sat Apr 02, 2011 9:57 am |
|
 |
|
hamw
Joined: Mar 31, 2008 Posts: 739
|
 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 [ 231.75 KiB | Viewed 1270 times ]
|
| Sun Apr 03, 2011 9:05 am |
|
 |
|
hamw
Joined: Mar 31, 2008 Posts: 739
|
 Re: osasubr hogging the cpu
At 8:30 PM. Have restarted SB and will observe.
Attachments:
SB Mem 20110403 pm.tiff [ 82.58 KiB | Viewed 1157 times ]
|
| Sun Apr 03, 2011 6:37 pm |
|
 |
|
hamw
Joined: Mar 31, 2008 Posts: 739
|
 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 [ 188.28 KiB | Viewed 1157 times ]
|
| Sun Apr 03, 2011 6:42 pm |
|
 |
|
hamw
Joined: Mar 31, 2008 Posts: 739
|
 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 |
|
 |
|
matt (support)
Site Admin
Joined: Jan 27, 2003 Posts: 11698 Location: Texas
|
 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.
_________________
|
| Mon Apr 11, 2011 7:54 pm |
|
|
|
Page 1 of 1
|
[ 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
|
|