- Posts: 276
- Thank you received: 0
Saving parameters after shut down
I need to be able to do the same thing,how do I write directly to the hard drive to save the last state of a parameter so I dont have to manually set the state of each of these on every power up? My logic is written as comp's in C. Suggestions?
Thanks
Please Log in to join the conversation.
..............................none of which have limit switches or sensors to indicate their position
You probably need to expand a little upon what exactly you will be saving.
Lost me a bit as to what the 'state' consists of, if it cannot determine where the items are.
If your component is a userspace one, then you can just use the standard file functions from stdio.h, but I suspect the reason you ask is because it is a realtime component?
One easy way to side step the problems of accessing devices from a realtime module, would be to write a userspace component whose sole function is to read parameters at start up and write them to disc when signalled at close down.
You could then just connect the userspace to the realtime component, via suitable HAL pins for your data type, and have a signal pin to trigger a read or write.
regards
Please Log in to join the conversation.
(I have cast the float pin to float* from volatile real_t*, don't know how that will pass through fscanf,
if there are problems you could just use an intermediary float variable to receive it and then set the pin value from that )
Please Log in to join the conversation.
You are correct,all of this is written as a realtime component.The userspace example is what I was looking for. Figuring machine logic is relatively easy,the c programming I know is from writing tool changers ,ect. Im kinda missing the how to use C part of using C for regular computer stuff,if any of that makes any sense!!!Thanks!!
Please Log in to join the conversation.
The example is back of an envelope stuff.
Occurred to me after posting that synchronising between a realtime and userspace component, it would probably be best to have a data-ready bit flag so that the realtime component knows that outvalue has been set to something meaningful .
Otherwise, unless you programmed a delay, it would send a read command and then immediately read the value of the pin which would probably still be 0 because it was being updated on a much slower thread.
regards
Please Log in to join the conversation.
JR1050 wrote: Thanks for the response. Let me see if i can explain.The chuck can be used to grab the part from the inside or the outside.It uses two solenoids to open or close the chuck.The chuck can be operated by a single foot switch or by mcodes.The control does not know whether the chuck is open or closed,so it gets a parameter,a bit,'" inside_chuck" or "outside_chuck" set. Right now im using a button to set the state of inside or outside,Id like to set it once and save the last known state.whether inside or outside,so on power up,the control knows the chuck is open(od grip) or closed(id grip).
Why not just have a selector switch for ID/OD chuck.
John
Please Log in to join the conversation.
In all honesty,it would be nice to save the tool # in the turret and on a machine like say my Brown &Sharpe mill,which can have a tool in the spindle,a tool in the ready pocket and the tool pocket on the tool chain,saving what is where saves a bunch of hassle in the morning when firing the beast up.If you get the tools out of sync,it can a while to get them right. Saving them,like modern machines do is the way to go. Ill post the code I have so far.Thanks as usual!!
Please Log in to join the conversation.
John
Please Log in to join the conversation.
Considering at the end of the day,after the last part is run,you leave the chuck open and the tailstock extended, and the normal position is chuck closed,tailstock back,the machine will be out of sync.My hardinge uses limit switches for everything,this machine,my Mori and my old Ikegai dont,they save the condition of the individual appendage as what it last was.I got the Ikegai confused once with the chuck,and it was a bear to get it right.
Please Log in to join the conversation.
ArcEye wrote: One easy way to side step the problems of accessing devices from a realtime module, would be to write a userspace component whose sole function is to read parameters at start up and write them to disc when signalled at close down.
You could then just connect the userspace to the realtime component, via suitable HAL pins for your data type, and have a signal pin to trigger a read or write.
How would one signal the file to read or write at close down or startup?
Regards
Marius
www.bluearccnc.com
Please Log in to join the conversation.
