Code Monkey home page Code Monkey logo

Comments (4)

egaltier avatar egaltier commented on August 29, 2024

Discussing with Nick, it turns out I just had to use x.nsl._config['rate'] = 1 to set the rate after initialization. So I tested the scripts and they do behave very closely to what I want (the DAQ doesn't make damaged event anymore and we save the right number of images). There is only one small behavior I would like to sort out. When I change the rate from 10 to 1 Hz, I want to make sure it is reversed back to 10 Hz just before the completion of the script which execute the rate change. So, I use op.x.nsl._config['rate'] = 10 at the end of the script to make sure the configuration of the plan has the right rate (for whoever takes the beam after, if not the current operator). While it seems to work (x.nsl.config does return a rate of 10), the actual GUI shows that the sync marker is still at 1 Hz. I have the feeling that it is because I dont run a plan to push for the configuration. If that's true, of course, I am not going to do this just to reset the rate back to 10 Hz. Would there be a less 'intrusive' way to make sure the sync marker is indeed back to 10 Hz?

from mec.

slactjohnson avatar slactjohnson commented on August 29, 2024

@egaltier if you change the configured rate back to 10, that will be pushed to the sequencer whenever the next shot plan is executed.

from mec.

egaltier avatar egaltier commented on August 29, 2024

Right, whenever the plan is executed. And I have check that this part works. I worry about this situation: we are done with a shift, but Eric C. wants to take some test shot for debugging purposes. He will not be using the scripts for the shots so there will be no plan that will push the sync marker back to 10 Hz. I have looked at his module and in theory it doesn't look like he is checking the sync marker at all. So I do believe we are ok. But it will be safer if we can make sure that the sync marker is pushed back to its original state, and trying to do so without pushing an entire plan (since I would assume this would be an overkill). Maybe we just toggle the value of the button's PV itself?

from mec.

slactjohnson avatar slactjohnson commented on August 29, 2024

It sounds like we need a special shot plan for this, as you suggested in your request. This should not be hard to do.

from mec.

Related Issues (6)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.