Overview
:
The
Low Level Communicator MxM is a low level but powerful
MxM.
It is a low-level MxM because it is not dedicated to a
special device and is able to use many raw communication
protocols.
But it is powerful for two reasons.
Five
types of communication available
- Serial
- TCP/IP Client
- TCP/IP Server
- UDP/IP Client-Server
- MIDI
Writing
of customized drivers
The programmer
can write its own set of commands, create monitoring variables
linked to the reception of specified frames, and much
more, in order to write drivers dedicated to specified
devices and projects
Note: When this MXM is used with Showmaster and when a TCP/IP server device is used, the external connection needs to be setup to address Medialon Showmaster Editor host during the programming process. When a programming process is done, the external connection can be setup again to address Showmaster.
> Top
Installation
(MXM):
No
specific installation is required.
> Top
Creation
(Device):
At
the creation of the device, a setup dialog with seven
main pages box pops-up.
These seven main pages are: Type, Frames, Checksum, Commands,
Answers, Monitoring, Automation.
All
these parameters are saved with the Manager project, as
all other MXMs, but they also can be saved in separate
drivers files. These drivers files can be re-used
in other projects ( see DRIVERS section).
TYPE:
Five type of communication are available: serial,
TCP/IP client, TCP/IP server, UDP/IP Client-Server, MIDI, which correspond
to five different parameters pages (
TCP/Server is not available in lite version ):
Serial parameters:

COM Port:
The number of the com port to use with this device. If
this port is used by another device, the name of the device
is written between brackets within the number of the port.
If a message says "Impossible to open this port" at the
time you close the dialog box or at the startup of the
device, it may be because this port has been opened by
another application or driver.
BaudRate, Stop bits, Data bits, Parity:
The setup at which the port must run at the startup of
the device.
DTR, RTS:
These two signals are present in the RS socket. In some
protocol, these signals are used to detect the start of
a frame, or to say if the device can send or receive.
Full Duplex / Half Duplex:
Full duplex is used with separate lines for sending and
receiving.
Half duplex is when the same line is used alternatively
for both.
Break character:
Break character is the character that will be set in the
frame for sending a break (low status) on the serial line.
Break
time:
The break time is the time that this break will last.
TCP/IP Client parameters
Address:
Address of the server on which this client will connect..
Port:
Port on which this client will connect.
Auto reconnection:
When this option is checked, the MxM will periodically
try to reconnect if it looses the connection.
Optimize small packets:
Check this option if you send small frames and if you
want to increase the speed of the transmiting.
It will set the TCP_NODELAY option in the Network system.
Enabling the TCP_NODELAY option disables the TCP Nagle
Algorithm (and vice versa). The Nagle algorithm (described
in RFC 896) is very effective in reducing the number of
small packets sent by a host by essentially buffering
send data if there is unacknowledged data already "in
flight" or until a full-size packet can be sent.
However, for some applications this algorithm can impede
performance, and TCP_NODELAY can be used to turn it off.
These are applications where many small messages are sent.
Application writers should not set TCP_NODELAY unless
the impact of doing so is well-understood and desired,
since setting TCP_NODELAY can have a significant negative
impact of network and application performance.
TCP/IP Server parameters (
TCP/Server is not available in lite version )

Port:
Port on which this server will listen.
Adapter for reception:
If "all"is checked, the server will listen on
all the network adapters present on the computer, if not,
it will listen on the specified adapter.
Optimize small packets:
Check this option if you send small frames and if you
want to increase the speed of the transmiting.
It will set the TCP_NODELAY option in the Network system.
Enabling the TCP_NODELAY option disables the TCP Nagle
Algorithm (and vice versa). The Nagle algorithm (described
in RFC 896) is very effective in reducing the number of
small packets sent by a host by essentially buffering
send data if there is unacknowledged data already "in
flight" or until a full-size packet can be sent.
However, for some applications this algorithm can impede
performance, and TCP_NODELAY can be used to turn it off.
These are applications where many small messages are sent.
Application writers should not set TCP_NODELAY unless
the impact of doing so is well-understood and desired,
since setting TCP_NODELAY can have a significant negative
impact of network and application performance.
UDP/IP parameters

Maximum input packet size:
This setting is low by default in order to minimize resources
usage. It can however be raised in order to receive bigger
UDP frames, up to a maximum of approximatively 64KB. All
frames above this size will be truncated when received.
Adapter for reception:
If "all"is checked, the MXM will listen on all
the network adapters present on the computer, if not,
it will listen on the specified adapter.
Port:
Port on which the MXM will listen.
Exclusive port:
If checked, the port will not be shared, no other application
can simunalteneously open it on the same computer.
Multicast:
Check this option if you want to specify a multicast address
for listening. (It is the responsibility of IANA to manage
the multicast address space [27, 1]. Multicast addresses
range from 224.0.0.0 through 239.255.255.255. The address
224.0.0.0 cannot be assigned to any group since it is
reserved. These addresses are permanent in the sense that
it is the address, not the membership of the group, which
always exists [15]. A permanent group may have any number
of members at any time, which can be even zero. Other
multicast addresses are temporary in nature and the groups
which they represent are called transient multicast groups).
Default Destination Parameters:
This is where you can specify a default address and a default port where
udp frames will be sent by the monitoring process( see the creation
of monitoring parameters ), and by the "Send Frame" command.
MIDI parameters

Output port:
Port on which the MXM will send MIDI frames.
Output port:
Port on which the MXM will receive MIDI frames.
FRAMES
:

Output :
Parameters used in the format of the output frames.
Checksum character:
Checksum character is the character that represents the
checksum in the frame and it will be computed before sending
the frame.
Hexadecimal character:
This is the ascii character used for sending an hexadecimal
character. For example, if the "!" is used, you can write
!0A!0D for sending a carriage return and a line feed.
Decimal character:
This is the ascii character used for sending a decimal
character. For example, if the "&" is used, you can
write &255 for sending this upper ascii byte.
Input:
These parameters define the validity of an input frame.
This validity is the one taken into consideration for
the device variable FramesCount (see below) to
indicate that valid frames have been incoming.
Count of bytes:
This is the count of bytes that the device waits for.
If ending or header character are filled (see below),
this parameter can be null: in this case all the bytes
between ending character and(or) header character fills
the frame.
Timeout:
This is the maximum time that can occur between two bytes
of a same frame. Each time this value is over, the device
empties its internal counter and waits for the first byte
of a frame. If this value is set to zero, the mechanism
is disabled. WARNING: if the timeout is set to zero and
the count of input bytes is also set to zero, the input
frame can become huge if it is not read out by "Get frame".
Header character:
When this character is received, it is considered to be
the first character of a frame. You can use the hexadecimal
character here (for example !02).
Ending character:
When this character is received, it is considered to be
the last character of a frame. You can use the hexadecimal
character here (for example !03).
Perform checksum verification:
If this option is enabled, the checksum is calculated
each time a frame is considered to be valid by the previous
parameters. The byte of the checksum must be equal to
the checksum byte before a frame is considered to be definitly
valid.
Convert
only the non-literal bytes to the hexadecimal format:
If a non literal byte (ascii value >31 and <127)
is received it is converted to the hexadecimel format,
using the "hexadecimal character" entered before.
Convert
all the bytes received to the hexadecimal format:
All the bytes received are converted to the hexadecimel
format, using the "hexadecimal character" entered before.
Keep
the original values:
When checked, nothing is converted.
Store
frames:
When checked, all the frames received are stored and you
can fetch them with the "Get frame" command. When unchecked,
only the last frame is stored.
Character replacement:
This section lists the character that must be replaced
in the frames before sending and replaced back the other
way upon reception.
Excluded/Replaced:
The left list contains the excluded characters, the right
list contains their replacement. On output excluded characters
are replaced by the corresponding string, and on input
the replacement string is transformed back to the original
characters.
Not for header/ending character:
Check this box if you don't want to aply the replacement
to the firt and to the last character of the frame.
Checksum before replacement:
Tells if the checksum (if enabled) must be calculated
before or after the character replacement phase. If the
checksum occurs before the replacement, then it is computed
on the original string and if the checksum value happens
to fall on a special character, it will also be replaced.
If the checksum occurs after replacement, it is computed
on the replaced string, and the checksum value itself
is not replaced if falling on a special character.
CHECKSUM

These
parameters define the checksum verification options. They
work together with the "checksum character" and "checksum
before replacement" options of the "Frames" config tab.
Checksum check can be enabled on input or output frames,
or on both. The first occurrence of the "checksum character"
will be replaced upon sending or reception by the appropriate
checksum, computed using the following options:
Checksum
Type:
This
allows to select the type of checksum of the frame:
Sum
This checksum is the sum of all the bytes between the byte indicated by 'Start from byte' parameter
and the byte before the checksum character or indicated by 'Stop at byte' parameter. Note: 'Checksum pos' parameter is not used.
Xor
This checksum is the result of a XOR operation of all the bytes between the byte indicated by 'Start from byte' parameter
and the byte before the checksum character or indicated by 'Stop at byte' parameter. Note: 'Checksum pos' parameter is not used.
Note: 'Count of Bytes' parameter is always 1 with this type.
Or
This checksum is the result of a OR operation of all the bytes between the byte indicated by 'Start from byte' parameter
and the byte before the checksum character or indicated by 'Stop at byte' parameter. Note: 'Checksum pos' parameter is not used.
Note: 'Count of Bytes' parameter is always 1 with this type. Note: This is a very inefficient checksum
but it is present in some protocols.
Crc16
This checksum is the two bytes result of a polynomial
calculation between the byte indicated by 'Start from byte' parameter
and the byte before the checksum character or indicated by 'Stop at byte' parameter.
Note: CRC stands for Cyclic Redundency Check).
Note: See 'Crc 16 mask' parameter definition for more details.
Note: See 'Crc 16 initial value' parameter definition for more details.
Note: 'Checksum pos' parameter is not used.
Level
Control System 7 Bit Checksum
This type of checksum is used by the Level System Control
Matrix3/Matrix4 protocol.
Alcorn
Mc Bride AMINet
This type of checksum is used by the Alcorn Mc Bride
AMINet UDP protocol (for the DVM4).
Start
checksum from byte (from start)
It indicates at which byte of the frame the checksum computation
must start (zero indexed). If this value is not set, the computation starts from the first byte.
Stop checksum at byte (from end)
It indicates at which byte of the frame the checksum computation
must stop (zero indexed). If this value is not set, the computation stops just before the checksum byte.
Checksum
pos
It indicates at which byte of the frame the checksum byte
is located (zero indexed).
Crc16
mask
This parameter indicates which members of the polynome are used to compute the CRC. Each bit corresponds to a member of the polynome:
- A001h (default value) which is commonly used in the industry indicates the polynome: x^15 + x^13 + x^0.
- The CCITT defines the value 1021h which indicates the polynome: x^12 + x^5 + x^0.
- Any other value can be used accordingly to the device protocol definition. Please refer to the device protocol documentation.
Crc16
initial value
This parameter indicates a constant value used to initialize the computation registers:
- 0000h (default value) is commonly used in the industry.
- The CCITT defines the value FFFFh.
- Any other value can be used accordingly to the device protocol definition. Please refer to the device protocol documentation.
High
byte first
When checked the order of the two bytes resulting of the
Crc16 is high-low, when not checked it is low-high.
Two's
complement
A (NOT+1) operation is performed on the checksum byte.
( also explained as 256 minus the value ).
ASCII
coded
The result of the operation is changed into ASCII characters.
Important note: if the size of the checksum is set to
1, the "ASCII coded" operation will create two
bytes, if the size of the checksum is set to 2, the "ASCII
coded" operation will create four bytes.
For example, with a size of 1 and a checksum result of
110 (in decimal) the two bytes will be the ASCII character
"6" and "E".
Count
of bytes
The count of bytes of the checksum: it is usually 2 for
the CRC16 checksum and 1 for the others.
COMMANDS
The
commands created in this section are added to the device
command set.
These commands can contain parameters where variables
can be used.
Important
Note: the name of a command fully identifies the command,
thus renaming a command must be processed with care. As
an example: if the "Play" command of a command
driver is used by cues of several Low Level Communicator
devices, renaming the command to "Play2" will
update the cues of the currently edited device. However
cues of the other devices will not be updated if the driver
is loaded into these devices.
Each command can belong to positrack groups. This positrack
mode is very useful when programming a timeline. If several
commands belonging to the same positrack group are used
in a timeline that is put in pause mode, only the last
command placed before the pause point is executed.
- User commands: the list of commands created.
- Positrack groups: the list of all the groups created.
- Inside this group: the list of commands that belong
to the group selected.
- Not inside this group: the list of commands that do
not belong to the group selected.
When you create a new command, tou can specify the name
and the output frame of this command.
In the output frame, it is possible to define parameters,
that will appear afterwards in the "Send User Command"
command.
In the frame, the syntax of the parameters are between
brackets.
It contains the name, the type, and the size of the parameter.
Five types of parameters can be specified: integer, string,
time, date and enum; it will be the type of the parameters
that will appear in the command cue.
Six modes of conversion can be specified:
- hexa: the bytes will be the ascii representation of
the hexadecimal value of the parameter.
- decimal: the bytes will be the ascii representation
of the decimal value of the parameter.
- bcd: the bytes will be the ascii representation of
the bibary-coded-decimal value of the parameter.
- low-high: the bytes will be the binary value of the
parameter, with the low byte first.
- high-low: the bytes will be the binary value of the
parameter, with the high byte first.
- literal:: the bytes will be the string value of the
parameter.
The size represents the minimum count of bytes that will
be sent: if the result of the conversion has only one
byte, zero is added first.
The enum type is different than the other because for
each item of the enum, you can specify tha name and the
value to be sent:

In the example above, a Power command has an enum parameter
called POWER that can have 2 values: OFF and ON. When
ON will be selected in the cue, the value !01!10 will
be inserted in the frame. When OFF will be selected in
the cue, the value !02!20 will be inserted in the frame.
ANSWERS
This page let you enter specific answers to frames received.
If "For each valid frame received, answer:"
is checked and if a frame is specified, this frame will
be sent each time any valid frame is received by this
device.
if "When receiving this valid frame" is checked,
you can specify a list of answers corresponding to a list
of specific valid frames received.
MONITORING
In
this page, you can specify a list of frames that will
be periodically sent.

- Fixed Length Character: character used in variable
definition to specify a fixed length unknown character
(default is 'X').
- Variable Length Character: character used in variable
definition to specify a variable length character string
(default is '?').
-
Period:The period if the time in tenth of seconds at
which the selected request is sent. Each request can have
a different period.
- Wait & timeout: If the "Wait for answer"
is checked, the device will wait from an answer before
another request is sent. If the answer is not received
within the time specified in the "Timeout" parameter,
the next request is sent.
You can also create monitor variables.
These variables will appear in the Variables Inspector
of Manager and will be automatically updated each thier
corresponding frame is received.
-
Linked: A request can be linked to a monitoring variable.
It means that the frame containing the variable will be
considered as valid only if the linked request has been
sent just before. If the protocol that you use does not
send the same answer format for several monitoring variables,
you don't need to use the "link" mode.
-
Disable request frames: This is useful when you are in
test phase: it disables the periodic sending of the request
frames.
After entering the name and the type of variable, enter
the waited frame.
Use the fixed length character (default is 'X') to specify
undefined characters.
Use the variable length character (default is '?') to
specify a undefined string of character.
To
determinate the position and the length of the bytes to
be monitored in the variable, select these bytes in the
frame before closing the dialog box.
-
Type: The types can be: integer, string, time, date
or enum.
When the type is integer or time, the variable is updated
with the binary value of the bytes received.
When the type is string or date, the variable is updated
with the literal value of the bytes received.
If the selected type is Enum the dialog box shows an enum
editor which allows to define the Enum.

-
Format:
- hexa ascci value: the bytes received are the ascii representation of the hexadecimal value.
- decimal ascii value: the bytes received are the ascii representation of the decimal value.
- bcd value: the bytes received are the binary coded decimal representation of the value.
- low-high bytes: the bytes received are binary bytes,with low byte first.
- high-low bytes: the bytes received are binary bytes, with high byte first.
-
Update Mode:
-
Immediate: The variable is updated when the frame is
received regardeless if the 'Store Frame' option is checked.
-
On 'Get last frame' Command: The variable is updated when
the frame is read with the command 'Get last frame'. If
there are some other frames already stored in the input
buffer, those frames must be read before the variable
could be updated.
Note: if the option 'Store Frames' is not checked
in the Frames tab, this option has no effect and the default
'Immediate' mode is used.
Note: when the value type is 'Integer', it is possible
to display the value in decimal or integer format in the dialog
box that opens when editing the value.
Examples:
if the variable type is integer with format "high-low
bytes" and the frame specified is VALUE=X (where
X is selected) and the frame received if VALUE=!02, the
value of the integer variable will be 2.
if the variable type is integer with format "high-low
bytes" and the frame specified is VALUE=XX (where
XX is selected) and the frame received if VALUE=!01!02,
the value of the integer variable will be 258 ( 102 in
hexadecimal).
if the variable type is string with format "high-low
bytes" and the frame specified is VALUE=X (where
X is selected) and the frame received if VALUE=2, the
value of the string variable will be "2".
if the variable type is string with format "high-low
bytes" and the frame specified is VALUE=X (where
X is selected) and the frame received if VALUE=!02, the
value of the string variable will not be a displayable
character because !02 is not a valid ASCII character.
if the variable type is integer with format "high-low
bytes" and the frame specified is VALUE=X (where
X is selected) and the frame received if VALUE=2, the
value of the integer variable will be 50 ( 50 is the decimal
ASCII value of "2", 50=32 in hexadecimal ).
if the variable type is integer with format "high-low
bytes" and the frame specified is VALUE=XX (where
XX is selected) and the frame received if VALUE=12, the
value of the integer variable will be 12594 ( 3132 in
hexadecimal, where 31 is the hexadecimal ASCII value of
"1", and 32 is the hexadecimal ASCII value of
"2").
if the variable type is integer with format "bcd
value " and the frame specified is VALUE=XX (where
XX is selected) and the frame received if VALUE=!01!23,
the value of the integer variable will be 123.
if the variable type is integer with format "hexa
ascii value " and the frame specified is VALUE=X
(where X is selected) and the frame received if VALUE=A,
the value of the integer variable will be 10.
if the variable type is integer with format "decimal
ascii value " and the frame specified is VALUE=XX
(where XX is selected) and the frame received if VALUE=14,
the value of the integer variable will be 14.
if the variable type is String with the Litteral String
format and the frame specified is "Status=?!0D"
(where '?' is selected) and the frame received is "Status=Playing!0D",
then the value of variable will be "Playing".
If the frame received is "Status=Paused!0D"
then the value of the variable will be "Paused".
- Avanced Monitoring Variable Setup:
Clicking on the "Advanced" button of the Monitoring Variable Setup Dialog allows setting Bit Mask parameters.

The Bit Mask parameters are useful when the monitoring value embeds information in particular bits.
A Bit Mask can only be applied to integer or integer enum values.
Available options are:
- No Bit Mask: no special bit mask processing is done on the monitoring value
- Use Bit: the monitoring value is equal to the value of the specified bit.
The value is '1' if the specified bit is set.
The value is '0' if the specified bit is not set.
For example, if the value is '36' ( '24' in hexadecimal format or '00100100' in binary format) and the specified bit is bit #2, the value of the monitoring variable will be '1' because bit #2 is set.
Note that bit numbers are zero based. Bit #0 is the rightmost bit in binary form.
- Use Bit Range: the monitoring value is equal to the value of the specified bit range shifted to the right by the specified 'Shifted By' value.
For example, if the value is '36' ( '24' in hexadecimal format or '00100100' in binary format) and the specified bit range is from bit #2 to bit #5 shifted by 2, the value of the monitoring variable will be '9'
('00001001' in binary format).
The Bit Mask processing is done after the format conversion ('Hexa ascii value', 'High-Low bytes', etc.) is applied.
AUTOMATION

This page tells when the device will make the connection
(for example the opening of the port for a serial device).
- On Manager start: the connection is done when Manager
enters run or debug mode.
- On "Open" command: the connection is done
only when the command "Open" is called.
- On sending: the connection is done just before sending
a frame.
- On Manager stop: the disconnection is done when Manager
enters stop mode.
- On "Close" command: the disconnection is
done only when the command "Close" is called.
- On receiving after xx ms: the disconnection is done
xx milliseconds after receiving a valid frame.
DRIVERS
The drivers can be saved into ascii files.
These files have the INI format and can be edited by double-clicking
on them.
They are located in the Low Level Communicator Drivers
directory of the MxMs folder of Manager.
These
drivers are used to store the parameters in another place
than the Manager project, so that they can be easily re-used
and exchanged.
After
the setup of the device is done, the driver file is no
more used since the parameters are saved also in the Manager
project.
If
a driver has been previously loaded from a file and the
parameters of this driver have been modified, the modifications
are automatically saved in the original file. However
the changes are not automatically applied to other devices
of the project which use the same driver. In order to
apply the modifications, the driver file must be manually
loaded in each of these devices.
Note that Low Level Communicator Drivers can also be
downloaded from the Medialon WEB site http://www.medialon.com/download/ktor_drivers/.
TEST
In this window, you can test the frames.
In can be useful for verifying a checksum, for example
The format of the frame that would be sent takes in account
all the parameters of the other pages.
> Top
Commands
(List Of):
Some
commands are available only for specified types. The types
are written into brackets besides the command.
User commands defined in the device setup are added to
this command set.
Open
(all types)
Definition
: Open the communication.
Parameters: no parameters
Usage: This command can be called if the opening
of the communication is not set to automatic in the
setup of the device.
Close
(all types)
Definition
: Close the communication.
Parameters: no parameters
Usage: This command can be called if the closing
of the communication is not set to automatic in the
setup of the device.
Send
frame (Serial, TCP/Client, MIDI,TCP/IP Server, UDP/IP Client-Server )
Definition
: Send the specified frame.
Parameters:
Output frame [Type: String] The frame
to send.
Usage: In TCP/IP server mode the frame is sent
to all of the connected clients. In UDP/IP Client-Server mode, the frame is send to the default destination address and port.
Send
frame to (TCP/IP Server) (
TCP/Server is not available in lite version )
Definition
: Send the specified frame to a client.
Parameters:
Output frame [Type: String] The frame
to send.
Address [Type: String] Address of the
client connected to send to. Several client addresses
(separated by a comma, space, dot, line feed or carriage
return) can be specified. The "ClientsList"
device system variable can be used as the address.
Send
frame to (UDP/IP Client-Server)
Definition
: Send the specified frame to a client.
Parameters:
Output frame [Type: String] The frame
to send.
Address [Type: String] Address of the
computer to send to.
Port [Type: Integer] Port of the computer
to send to.
Get
last frame ((Serial, TCP/Client, MIDI)
Definition
: Read a frame from the next incoming frame buffer list.
Parameters:
Input frame [Type: String] The string
that will be filled with the incoming frame in return.
Usage: This command must be called when the
variable FramesCount (see below) becomes not
null. This variable indicates the count of incoming
frames waiting to be read.
Each time a frame is read with this command, the variable
FramesCount is decreased by one and the frame
read is punched out of the buffer list.
Get
frame (TCP/IP Server, UDP/IP Server)
( TCP/Server
is not available in lite version )
Definition
: Read a frame from the next incoming frame buffer list.
Parameters:
Input frame [Type: String] The string
that will be filled with the incoming frame in return.
Client address [Type: String] The address
of the computer that has sent the frame.
Usage: This command must be called when the
variable FramesCount (see below) becomes not
null. This variable indicates the count of incoming
frames waiting to be read.
Each time a frame is read with this command, the variable
FramesCount is decreased by one and the frame
read is punched out of the buffer list.
The addresses can be retreived in the ClientsList variable.
Get
byte (all types)
Definition
: Read a byte from the last incoming frame.
Parameters:
Return ascii value [Type: String] The string
that will be filled with the byte value (see usage)
Byte index [Type: Integer] The index of the
byte in the frame
Usage: This command can be called when the variable
FramesCount is not null. When a byte is read
with this command, the variable FramesCount is
NOT decreased by one and the frame remains in the list
(see command above: "Get Frame" for punching out the
frame).
The Return ascii value can contain an hexadecimal
representation of the byte, if it is not litteral, like
it has been set in the setup of the device for the sending
of hexadecimal character ( for example !0D )
Change
count of bytes (all types)
Definition
: Change the count of byte that the device is waiting
for (incoming count of bytes).
Parameters:
Count of bytes [Type: Integer] New count of
bytes.
Usage: In many protocols, the count of by of
the responding frames depends of the type of command
frame sent. This is the purpose of this command.
Set
DTR (serial)
Definition
: Change the DTR signal.
Parameters:
DTR value [Type: Integer] New value (0 or 1).
Set RTS (serial)
Definition
: Change the RTS signal.
Parameters:
RTS value [Type: Integer] New value (0
or 1).
Get
client name (TCP/IP Server)
( TCP/Server
is not available in lite version )
Definition
: Return the name of the specified client.
Parameters:
Address [Type: String] Address of the client.
Return name [Type: String] The string that will
contain the address in return.
Change
IP parameters (TCP/IP Client, TCP/IP Server, UDP/IP
Server)
( TCP/Server
is not available in lite version )
Definition
: Set new IP parameters for this device.
Parameters:
Address [Type: String] New address.
Port [Type: Integer]: New port.
> Top
Variables
(List Of):
Only
the default variables are listed here.
New variables can be created in the Monitoring page of
the setup dialog.
Status
:
Type
: Enum.
Description: Status of the connection.
Available values:
Closed: the connection is closed.
Opened: the connection is opened.
Error: no connection due to an error.
Adapter Address Error: The specified adapter address
for reception is not present in this machine.
LastCommandStatus
:
Type
: Enum.
Description: Status of the current command.
Available values:
Success: the command has been succesfully executed.
Pending: the command is currently executed.
Error: the command could not be executed.
Frames
count:
Type
: Integer.
Description: Count of incoming frames.
Usage:: This variable indicates the count of
incoming frames waiting to be read.
Each time a frame is read with the command "Read frame",
the variable FramesCount is decreased by one
and the frame read is punched out of the buffer list.
Input bytes count:
Type
: Integer.
Description: Count of incoming bytes of the
current frame.
Usage:: This variable indicates the count of
incoming bytes that are filling the current frame. If
there are several frames in the queue, it does not represent
the total of bytes of all the frames, but only the count
of bytes of the last frame received. It can be useful
when the parameters "count of bytes" and "timeout" are
set to zero in the setup of the device with a protocole
with variable length frame.
Last
received frame:
Type
: String.
Description: The last frame received on input.
Usage:: You can use this variable for reading
the input frames, but be aware that if the frames arrive
too fast, the variable can be overwritten by the next
frame, while you read it (if it is the case, use "Keep
all the input frames in memory" and the "Get Frame"
command).
Clients
count:
Type
: Integer.
Description: Count of connected clients (in
TCP/IP Server mode).
Clients
list:
Type
: String.
Description: List of connected clients.
DSR
status:
Type
: Integer.
Description: Current DSR status (serial device).
CTS
status:
Type
: Integer.
Description: Current CTS status (serial device).
> Top
Support
(Difference with previous versions):
V 1.0.1:
- Bug
Fixed: crash if a negative value is used as an index of an enum parameters in a user command.
V 1.0.2:
- Added: Support for Showmaster.
V 1.0.3:
- Corrected: Button font color corrected in the setup dialog.
- Modified: "Automation/On project load" and "Automation/On project unload" options have been removed from the setup dialog.
- Corrected: The value was not returned by "Get Last Frame" if the return variable was not a string type.
- Corrected: The value was not returned by "Get Byte" if the return variable was not a string type.
- Corrected: When "Get Byte" was called, the expected count of byte was changed in the setup.
- Fixed: False error detected when loading a project with deleted (strikethrough) cues. This bug fix requires Manager 5.0.2 or higher.
- Fixed: Crash when sending a user command with a very large command frame containing user parameters.
- Fixed: The break character is not analyzed if the frame does not contain a check-sum.
V 1.0.4:
- Fixed: random crash when "Get Last Frame" command is executed while receiving data.
- Fixed: Incorrect parsing of variable data from incoming frame with fixed and variable length bytes.
- Fixed: In the setup, the user can enter the same character for all the special character.
- Modified: better TCP Client Connection/Disconnection management if the specified server machine is not present.
- Fixed: user command enum variables are not created if the command frame length is greater than 4Ko.
- Fixed: user command frames are truncated when read from the driver file if the command frame length is greater than 2Ko.
V 1.0.5:
- Fixed: impossible to specify the address and the port to which the monitoring udp frames are periodically sent (fixed by adding default destination parameters).
- Improvement: "Send Frame" can be used in UDP Client-Server mode (with the default destination parameters specified in the setup).
- Improvement: When the setup of a device using a driver is changed, the user is offered three possibilities of saving ( device only, device and driver, new deriver ).
- Fixed: Incorrect parsing of variable data from incoming frame with fixed and variable length fields when the variable monitoring frame segment also contains regular (non wildcard) characters.
V 1.0.6:
- Fixed: In the setup, adding a parameter at the start of a command deletes the whole frame.
- Fixed: the command text is not computed if it starts by the bracket of a parameter description.
V 1.0.7:
- Fixed: Incorrect parsing of variable data from incoming frame with fixed and variable length fields when there are one or more fixed length fields after the last variable length field.
- Added: Support for Showmaster Pro.
V 1.0.8:
- Added: Monitoring Variable bit mask processing.
V 1.0.9:
- Fixed: Inner values of IP Address containing leading zero are converted from octal values instead of decimal.
V 1.0.10:
- Fixed: Default UDP parameters are not used in User Commands and 'Send Frame To' command (UDP mode).
V 1.2.0:
- Fixed: Cannot create more than 255 LowLevelCommunicator devices.
V 1.2.1:
- Fixed: a parameter of a driver command is not processed if it is larger than 2048 bytes.
> Top |