Serial Plugin to Receive Data from Linn Unidisk SC

[Marchino]

Hi

I have Girder configured with the serial plugin to send commands to my Linn Unidisk SC, this works perfectly hooked up to Netremote. When the Unidisk receives serial commands, it replies with a response terminated by 0d0a, I would like to use this reponse to send further commands to the Unidisk.

e.g. I wish to use one button from Netremote to issue a mute or un-mute to the Unidisk based on the current state of the mute, instead of a Mute On button and a Mute Off button.
send $MUTE ?$ - get mute status
if reply = !$MUTE ON$ then
send $MUTE OFF$
else
send $MUTE ON$
this could also apply to other functions, cd drawer state, open if closed and close if open, etc.

I'm really struggling at the moment, I have read many posts and looked at various other serial based functions on how to get the received info, but I just cant get my head round it.

Hope someone can help, thanks.

Marchino

[Mark F]

Could you provide a link to the serial protocol (command syntax) for this component? I'd like to understand the full extent of the protocol before making any suggestions. Thanks. :)

[Mark F]

Marchino provided the document in a PM.

What a great manual!

I would suggest a couple of things:
When Girder initializes, send a group of commands to query the current state of the player.
Turn on the "unsolicited RS-232 feedback" function.

With both of these, you can use LUA code (look for "receive event handler" in the Serial plugin readme) and variables to keep track of the current player state. When you want to taggle the mute, you can inspect a LUA variable and send the command that changes to the other state. When that command completes, the player will send a response that you can parse and save the new state of mute.

These are the ideas I would persue. I don't have time to do this for you as work is really cramping my free time. :D However, if you get stuck or need to ask quesitons, please do so here and someone will help you as they can.

[Marchino]

Not too sure what you mean by "receive event handler".

Do you mean the serial plugin receive message definition?

[Mark F]

Sorry about that. I am talking about a LUA script that runs every time data is received from the component.

In the Serial plugin readme, look for "Scriptable events" and "Character Event".

Using this capability, you can use the LUA code to parse the incoming data, figure out what the data means and save the information in other LUA variables for later use.

[Marchino]

Think I'm getting somewhere.

The Unidisk responds in text, the only thing I need to put in the receive message definition is: variable length, 0d0a for terminator and strip. I have defined a receive script that sets a variable: SCState = SerialValue

On the mute command I have the following script:

SCCommand = '$MUTE ?$'
SERIAL_SendData('Unidisk SC', SCCommand) ------ queries state of mute
if (SCState == "!$MUTE OFF$") then
SCCommand = '$MUTE ON$'
else
SCCommand = '$MUTE OFF$'
end
SERIAL_SendData('Unidisk SC', SCCommand)

This works as expected, though on the very first execution (when SCState has no value) nothing happens, which leads me to believe that the script has executed the IF statement before the response has been received (SCState variable set to current state) from the query of the mute state.

Is there anyway of putting in a delay before the IF, so it can wait to get the response of the current mute state, and then go on to do the IF compare? Or am I going about this in the wrong way?

[Mark F]

You are going about it he wrong way. ;)

You should send the query from the Enable script. On the settings page, there are script buttons for the enable and disable events. In the Enable script, do this:


SERIAL_SendData('Unidisk SC', '$MUTE ?$') ------ queries state of mute


The receive event should save the response long before you need it.

Everything you send to the player will probably cause data to be sent to the serial port so I think you will eventually need to break the returned data into parts and save the settings.

For example, you may want to place a line defining a table in the enable script, like this:


SCStatus = {}


Then, in the receive event script you could do the following:


-- break the SerialValue into two strings
_,_,indx,val = strfind(SerialValue,"(%w*) (%w*)")
-- use the first string to index the array and save the second string
SCStatus[indx] = val


In any command where you want to inspect the value before deciding what to do you would do something like this:


-- check the last MUTE status to decide what to do
local SCCommand = ""
if (SCStatus["MUTE"] ~= nil) and (SCStatus["MUTE"] == "OFF") then
SCCommand = '$MUTE ON$'
else
SCCommand = '$MUTE OFF$'
end
SERIAL_SendData('Unidisk SC', SCCommand)

[Marchino]

Ok, but surely every time a command is sent to the serial plugin, it will execute the Enable script which queries the mute status? What if I wish to query the status of the cd drawer, do I put that command in the Enable script as well?

[Mark F]

The enable script only runs once. When the device is enabled. You do NOT need to query the status every time you want to send a command.

If you want to keep track of the CD drawer status, query it in the enable script as well.

As I said in an earlier post:


I would suggest a couple of things:
When Girder initializes, send a group of commands to query the current state of the player.
Turn on the "unsolicited RS-232 feedback" function.


Use the enable script to do both of these.

Every time you send a command to the player, the status will be returned. The receive event script will then save the returned state data and the current state will be available when you want to send the next command.

[Marchino]

Mark F, thanks for your help.

It took me a little while to get my head round the concept and change my way of thinking, but now works brilliantly. I'm off to do a bit more work on other commands, but no doubt I will have some more questions. :)

[Mark F]

Cool. I may have force-fed you a bit too quickly. Sorry. I'm glad you got this working and don't hesitate to ask more questions. :)