Home› AMX User Forum› AMX Technical Discussion

Casio Projectors

regallionregallion Posts: 95
in AMX Technical Discussion
Anyone had any experience with Casio LED projectors? I'm working on a project with two Casio XJH1700s.

The protocol is dead simple (e.g. "(PWR1)" to turn on), but we're experiencing really sporadic reliability. The projectors seem to ignore about commands sent to it 75% of the time.

AMX aside, we've also seen this with direct hyperterminal comms from our laptops.

It's not just the power commands either, it's all of them. I can send a Blank On request which it will perform, then it will systematically ignore subsequent Blank Offs. Same for get lamp life, same for get power status.

- Comms settings are as per the manual (19200, 8, n, 1).
- I've waiting from 5 seconds to 5 minutes between each command so I don't believe it's "still processing the last command".
- Cables are fine. I've tested using 3 different serial cables (including my old faithful never fails cable I always carry with me!)

I've logged a call with Casio tech support who are still investigating, but we've installed two of these things on a client site today and due to finish up in two days.

I'm wondering if these things are still quite new tech, so they've got some odd comms problems in the firmware that no-one has found yet.

Wondering if anyone here has used these over RS-232 successfully? (This particular model doesn't have ethernet alas).

Thanks in advance chaps!

Comments

  • a_riot42a_riot42 Posts: 1,624
    I've seen similar behavior with other devices, and typically it ends up being the end of line character or some other signalling character. Perhaps its waiting for that to be sent, and then times out after some period. The other thing to make sure of is the wiring. If you are only needing 2, 3, and 5 pins, make sure all others are disconnected at both ends, or you will put the comm port in RS422 mode.
    Paul
  • regallionregallion Posts: 95
    The cables we've tried include just the 3 pins and fully wired up.

    Well the manual doesn't specify a CR or such, but I did try it to to avail. I must agree with you though - the behaviour is just like as you describe. It's as if it is waiting for a terminator of some kind.
  • a_riot42a_riot42 Posts: 1,624
    regallion wrote: »
    The cables we've tried include just the 3 pins and fully wired up.

    Well the manual doesn't specify a CR or such, but I did try it to to avail. I must agree with you though - the behaviour is just like as you describe. It's as if it is waiting for a terminator of some kind.

    Then you may need the the CTS/RTS wires, it will depend on the pinout. Typically I check for correct wiring, then the command protocol, then the device firmware, and if all that doesn't work, I throw the device at the nearest installation technician :)
    Paul
  • regallionregallion Posts: 95
    Well like I said, I've tried fully wired CTS/RTS cable as well as just 3 pins. The manual actually does say no flow control though, so it's all very confusing.

    Time to throw the device at the installation engineer!
  • AuserAuser Posts: 506
    If you're pasting into Hyperterminal and not just typing character by character, I would try increasing the delay between transmitted characters using the CHARDM send_command to the serial port. See the manual for the control system you are using for instructions on using the CHARDM command.
  • a_riot42a_riot42 Posts: 1,624
    Auser wrote: »
    If you're pasting into Hyperterminal and not just typing character by character, I would try increasing the delay between transmitted characters using the CHARDM send_command to the serial port. See the manual for the control system you are using for instructions on using the CHARDM command.

    That is certainly something to always attempt, although I can't say I've ever needed to use it. I've used it and then realized the problem was elsewhere and undid it. I've seen it solve problems in an incidental way, because the programmer was not buffering commands properly so slowing down the characters helped, but it was the right solution for the wrong problem. If the manual says no hardware flow control then you won't need CTS/RTS wires. Why don't you post how you are initializing the comm port? Perhaps there is an issue there. I suspect wiring though.
    Paul
  • regallionregallion Posts: 95
    Nothing funky in the init:
    SEND_COMMAND dvProjector1, "'SET BAUD 19200,N,8,1 485 DISABLE'"
SEND_COMMAND dvProjector1, "'HSOFF'"				// Disable hardware handshaking

    And it behaves the same way with my laptop - I'm actually using a program called "DockLight" which has more features than hyperterminal.

    I'm going to mess with flow control today - manuals can be wrong!
  • geraldholdsworthgeraldholdsworth Posts: 61

    Did you get anywhere solving this issue?
    I've found something similar on a year old Casio projector which I am just introducing to the AMX controller. Like, for example, last night it did not get turned off, so I turned it off manually. Then this morning, it turned on, as it should.
    This is following on from successful tests after I reprogrammed the controller to control the projector.

  • John NagyJohn Nagy Posts: 1,742

    We had a similar behavior with the now-antique FAOUDJA line doublers. With them, we had to build a character-by-character delay of command content to get reliable results.

    Also try (if it lets you) resetting the baud rate to something sane like 9600. The faster baud rates are less forgiving. What's the hurry anyway?

  • John NagyJohn Nagy Posts: 1,742

    Another common dodge for unreliable commands is to macro a series of the same commands.
    ON ON ON ON ON with a couple seconds between. 5 times more reliable. Sorta, sometimes.

  • geraldholdsworthgeraldholdsworth Posts: 61

    I did think about reducing the baud rate.

    What I reckon is happening is that when the exhibition turns on, the equipment is turned on gradually - i.e. a load of WAITs (well, 7) to turn certain bits on at a time. But, when it is turned off, everything is set to turn off at the same time. I believe this is overloading the processor so I've re-written the turn off procedure to do it gradually (I've actually adapted the turn on and used a flag to indicate what is happening).

    In addition, I've set up a polling timeline which is going to ensure that everything in the exhibition that should be on, is on...or off, when it should be off. It was originally written that way for the original kit put in 12 years ago.

  • John NagyJohn Nagy Posts: 1,742

    You can't "overload" the NetLinx by turning everything off "at the same time" - unless you are actually specifying a time (to the second or more precision) for the OFF, in which case the single threaded processor might not get to all the commands before the specified time was no longer valid. I doubt you do that. Tell the Netlinx to do 50 things, it will do them all, one at a time.

    Let us know what you ultimately find. Many odd problems are solved, but without sharing, they must be guessed at again and again.

Sign In or Register to comment.