Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: Laser Star Wars Game with Unity3d plugin ILDA/Etherdream driver. Need advice

  1. #11
    Join Date
    Feb 2008
    Location
    East Sussex, England
    Posts
    5,205

    Default

    For decent priced ILDA cables look at Cables2Go DB25 Extension leads. Well priced and durable and available lots of places.

    http://www.ebay.com/sch/i.html?_odkw...nsion&_sacat=0

    For some reason the UK ones seem to be cheapest. Those are the ones anyway.
    http://www.facebook.com/SubsonicSystems
    http://www.frikkinlazors.co.uk

    You are using Bonetti's defense against me, ah?

    I thought it fitting, considering the rocky terrain.

  2. #12
    Join Date
    Jan 2014
    Location
    North Carolina, USA
    Posts
    219

    Default

    Quote Originally Posted by swamidog View Post
    the relay firing is the ED sensing an error with the data connection and actuating the interlock to kill projector output. this is absolutely intended to happen on buffer under/over run conditions. i'm sure jacob can speak more about it.
    I think it is more of a documentation problem - as there is no concept of buffer fill rate from the perspective of a user of the ED driver. It is obvious that there is indeed a rate which must be maintained (i.e. minimum amount of points in the write call) - as well as an amount which must not be exceeded. There is no notion of a rate from the ED API - It is implied though, by the fact you are calling etherdream_write() with a buffer size, and then waiting on driver to report that it is ready to receive more points.

    This reporting of "ready" is not documented very well - and is called: etherdream_wait_for_ready() - this is the blocking call that is supposed to tell you when it is ok to send the ED some more points. Does it really mean the ED is ready for points or is it expecting a delay before calling etherdream_write()

    What I mean, should both of the loop sequences behave the same - does the ED driver expect there to be a small processing delay after it reports that it is ready, or is it ok to immediately blast points?

    while(show_on)
    {
    process_points(pt_array)
    wait_for_ready()
    write()
    }

    while(show_on)
    {
    wait_for_ready()
    process_points()
    write()
    }

    I know you probably don't have the answers to these questions swami, but these are some of the ambiguous issues exposed by the ED API.
    Last edited by BlueFang; 01-06-2015 at 21:11.

  3. #13
    Join Date
    Jan 2014
    Location
    North Carolina, USA
    Posts
    219

    Default

    Here is a link to the jsfiddle page that cmb and I worked on last weekend.

    Some notes about this little project:

    The purpose of this little adventure was to explore some ideas with concrete implementations for optimizing a frame of points -an online playground of sorts for optimization ideas and algorithms. JSFiddle was the first thing I thought of when putting together this online playground. There are probably other services that could have been used - other languages.

    It is not intended to prove that Javascript is the greatest programming language (it is so not).
    It is not intended to imply that Javascript is an appropriate language for real-time processing of ILDA data.
    It is not intended to show highly optimized vector & 2d point processing code. It is intended to be easy to understand without much prior knowledge of the code.

    It is intended to show that I have no clue what I am doing with regard to optimization - but the more I experiment, the more I learn. And the more I play around with the optimization settings in LSX, the more I learn about how a professional level laser display application optimizes points.

    There are probably bugs in the code. There is probably incorrect handling of blanking points. It is absolutely definitely a Work In Progress!

    Being a jsfiddle page, anyone can dive in and help out!

    http://jsfiddle.net/BlueFang/wj7tsqLe/5/


    edit... updated to v.5 of the jsfiddle - currently the latest version.
    Last edited by BlueFang; 01-06-2015 at 21:06.

  4. #14
    Join Date
    Dec 2014
    Posts
    8

    Default

    i did some experiments last night based on what you said. It helps but doesn't completely fix my problem.

    ps. the DLL doesn't have wait_for_ready, but it does expose a get status which seems similar since i can heck for ready or busy.

    Quote Originally Posted by BlueFang View Post
    ...as there is no concept of buffer fill rate from the perspective of a user of the ED driver. It is obvious that there is indeed a rate which must be maintained (i.e. minimum amount of points in the write call - as well as an amount which must not be exceeded. There is no notion of a rate from the ED API - It is implied though, by the fact you are calling Etherdream_write() with a buffer size, and then waiting on driver to report that it is ready to receive more points.
    The python example that draws a square, has something like this.

    1) given a response, it reads the buffer fullness
    2) computes cap from the previous response
    3) uses a coroutine to generate Cap number of points
    4) writes cap number of points to ethernet.

    the driver doesn't have buffer fullness or cap exposed.


    REALLY what would be nice is if the etherdream firmware(not the driver) was implemented as a what i call "double buffered circular buffer".

    It has a section of the buffer that it is drawing. and it will repeat drawing it until it gets written too.
    When you write to it, it appends the new points the buffer, after the set of points that are currently being drawn.
    When the points are finished being written, the points that are being drawn, finish being drawn, but the updates the section of the buffer that is looping.

    just to illustrate the idea

    frame 1
    [x][x][x][x][x][x][A][C][T][I][V][E][x][x][x][x][x][x][x][x][x][x][x][x][x]
    points marked ACTIVE are being looped, x are invalid. The number of x are the max number of points that we can write. Any more will be discarded.

    writing a new frame
    [x][x][x][x][x][x][A][C][T][I][V][E][n][e][w][p][o][i][n][t][s][x][x][x][x]
    points marked ACTIVE are still being looped, points marked new points are filling in

    points are done being written
    [x][x][x][x][x][x][a][c][t][i][v][e][N][E][W][P][O][I][N][T][S][x][x][x][x]
    active points are still drawing displaying, but at the the system will continue on to the new set of points. points marked NEWPOINTS are the extents of the loop.


    system has finished drawing active points and has continued to NEWPOINTS
    [x][x][x][x][x][x][x][x][x][x][x][x][N][E][W][P][O][I][N][T][S][x][x][x][x]
    points marked NEWPOINTS are looping.

    the cool thing about this idea, is that is robust and safe if the network or driving application has a hic-ups. No interlock is needed if the network goes down. Since the beam keeps moving on the set of points that is has marked for looping.



    Im going to email jacob to ask him for advice.
    Last edited by alphasuede; 01-06-2015 at 20:50. Reason: details

  5. #15
    Join Date
    Jan 2014
    Location
    North Carolina, USA
    Posts
    219

    Default

    Quote Originally Posted by alphasuede View Post
    i did some experiments last night based on what you said. It helps but doesn't completely fix my problem.

    ps. the DLL doesn't have wait_for_ready, but it does expose a get status which seems similar since i can heck for ready or busy.
    Oh yeah... I forgot to mention I am working with the Mac OS X (linux) version of the DLL - called libetherdream - and it looks like the interface (header file) is a bit different than the Windows version. Here as link to the Mac header file:

    https://github.com/j4cbo/j4cDAC/blob...m/etherdream.h

    But yes, wait_for_ready() seems to be similar to get_status().

    Also, just to note... I am also able to get professional software like LSX to hang the ED (and by hang, I mean to fire the protection relay) - once this interlock relay fires, the host software seems to go into an unrecoverable state (i.e., I have to exit LSX in order to get the ED to start responding again). I have not figured out why that is - but it is always the case.

  6. #16
    Join Date
    Jan 2014
    Location
    North Carolina, USA
    Posts
    219

    Default

    Quote Originally Posted by alphasuede View Post

    The python example that draws a square, has something like this.

    1) given a response, it reads the buffer fullness
    2) computes cap from the previous response
    3) uses a coroutine to generate Cap number of points
    4) writes cap number of points to ethernet.
    That is interesting... The test.c file for libetherdream is much simpler:

    Code:
    i = 0;
    while (1) {
    	fill_circle((float)i / 50, mode);    // creates an array of 600 points based on polar coordinate math
    	int res = etherdream_write(d, circle, CIRCLE_POINTS, 30000, 1);  // CIRCLE_POINTS is the number of points in the array = 600
    	if (res != 0) {
    		printf("write %d\n", res);
    	}
    	etherdream_wait_for_ready(d);
    	i++;
    }

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •