I am sure this is much simpler than I'm making it out to be, but...
In CAPL, I'm trying to ouput the timestamp for signals that have a certain value:
on signal_update XXX
{
if ($XXX == 42) {
message * msg = { DLC = 15 };
getThisMessage(msg, 15);
write("Time: %f", messageTimeNS(msg));
}
}
So given a signal update, how do I get the containing message and its timestamp? (BTW, the 'DLC=15' is just the maximum value that the compiler let me include. I'm unsure of the correct value.)
You can always get the current simulation time by using
timeNowNS();
while you are in a on signal_update ... block, the time returned is the time which caused the event handler to be executed; in this case when a message was received which contained the signal of interest.
The simulation time will not change during execution of the event handlers.
Related
So I have an EA which places a Pending Order at the opening price of the current candle, and expires at the end of the current candle.
My code is below, I have even printed an error function in order to diagnose any errors that may occur, however, according to the EA, a pending order is placed so no error appears.
Sometimes a pending order is actually successfully executed, and other times, it tells me a pending order has been placed successfully, but no pending order appears on the chart.
There are no error messages.
Clearly there are no errors, so it must be something to do with my coding. What am I missing here? Why does it sometimes placed a pending order on the chart, and others times it decided not to?
Many thanks.
if(<Conditions are met>){
int pendingExpiration = Period() * 60;
double candleOpenPrice = iOpen(Symbol(),0,0);
double pendingOrderExecPrice = NormalizeDouble(candleOpenPrice,Digits);
if(!OrderSend(Symbol(),OP_BUYSTOP,3,pendingOrderExecPrice,100,<sl>,<tp>,0,1,Time[0] + pendingExpiration,0)){
RefreshRates();
Print("Error on pending order "+IntegerToString(GetLastError(),0));
}
else {
<confirmaion email function>
}
}
Only thing I see is the Digits thing:
Yours: NormalizeDouble(candleOpenPrice,Digits);
What I know: NormalizeDouble(candleOpenPrice,_Digits);
Notice the underscore.
Although not sure whether this causes the errors.
Your call to candleOpenPrice just might sometimes return too many (or few) digits that can not be casted by the erratic call to _Digits.
I have some questions on EPOLL when using Edge Triggered and with EPOLLONESHOT.
The simplified sequence of statements are listed below. Actually multiple files are monitored by an Epoll Fd and a set is managed through a specific thread. The variable names used speak for themselves and are, of course, set. That part is omitted for the sake of brevity:
1. Create epollFd
epollFd = epoll_create1(EPOLL_CLOEXEC);
2. Create events to monitor
epollEventParam.events = EPOLLIN | EPOLLPRI | EPOLLERR | EPOLLHUP | EPOLLET | EPOLLONESHOT;
3. Add the FD to monitor and the events
epoll_ctl(epollFd, EPOLL_CTL_ADD, socketFd, &epollEventParam);
4. While loop with epoll_wait
while (1) {
noFdsEvented = epoll_wait(epollFd, epollEventsReported, maxEvents, -1);
/***************** REARM Here or after processing the events? ******/
epoll_ctl(epollFd, EPOLL_CTL_MOD, (int)epollEventsReported[i].data.fd, &epollEventParam);
/** if EPOLLIN, read until read returns EAGIN ***/
//Relevant code to read...
//After EAGAIN is returned, REARM Here instead of doing so earlier (above)?
/** if EPOLLOUT, write until write returns EAGIN ***/
//Relevant code to write...
//After EAGAIN is returned, REARM Here instead of doing so earlier (above)?
/*** If other events... process accordingly ***/
}
QUESTIONS:
When EPOLLONESHOT is used, when should EPOLL be REARMED? After the event is received or after the event is processed?
Elementary. When writing or reading, we keep track of the data point written/read until EAGAIN was returned or if partially read/written? Yes/No.
Initially EPOLLOUT is not set. When writing, when write returns EAGAIN, we add EPOLLOUT to the event
to be monitored. Yes/No?
When EPOLLOUT is triggered again for an FD, we continue writing from the point EAGAIN was last received
and do so until we get EAGAIN again. THen we REARM. Yes/No?
If we read partially and do not REARM, new data will continue to arrive but no event will be triggered.
So, if we read partially, we need to keep track of it and not rely only on the event handler to do read processing. Right?
I can't answer all of them, but I can try to answer a few.
Elementary. When writing or reading, we keep track of the data point written/read until EAGAIN was returned or if partially read/written? Yes/No.
For read/recv: you should handle all of the following scenarios
If you read/recv EAGAIN or EWOULDBLOCK. This indicates that there is nothing left to read/recv and you should break from the receive loop.
You receive 0 bytes. This indicates that the other side is no longer connected
You receive 0 > bytes. You successfully read/recv data and should read/recv again.
You dont necessarily need to keep track of the data as opposed to just ensure you handle the above 3 scenarios.
Initially EPOLLOUT is not set. When writing, when write returns EAGAIN, we add EPOLLOUT to the event to be monitored. Yes/No?
Yes...I believe that in the instance where EPOLLOUT is initially set, the same behaviour on the send() FD should occur as you described in the question...given that you will simply write to the FD regardless of the event notification and only stop once you get an EAGAIN/EWOULDBOCK error.
I have a configuration setup with two CAN nodes and an attached database. I have added a CANOEILNLVECTOR.dll to both the nodes. By adding this Dll file all my messages are sent cyclic as I see in trace window.
Now I set some value for a signal in a message, For Eg:
variables
{
message Battery_Traction Batt_msg;
}
on start
{
Batt_msg.Isolation_Signal = 0x02; //0x02:On
output(Batt_msg);
}
What I see on trace is: The message is cyclic but only for the first instance the value set by me above appears in trace. For all of the rest times the signal value in the message in set to default.
As seen in the image value 0x02 is sent only once.
I am not sure what could be the problem, as seen in image attached value set by me is only sent once.
When using output you are putting the message directly onto the CAN bus, but you are not changing the value inside of your (simulated) node, so the interaction layer is still sending the old value.
You can change the signal value in the interaction layer by just putting a $ in front of the signal name and set the value.
In your case most likely $Isolation_Signal = 0x02
Outputting the message on the CAN bus at the right time, with the right cycle time and so on will be handled by the interaction layer.
You have two ways to influence dynamically the value of your message: IL DLLs and custom message sending.
Custom message sending is the basic way, where
you define the message ex.: message Battery_Traction Batt_msg;
you trigger its sending(output function)
you set up cyclic sending on timer Cycletimemsg1 {output(msg1);}
and so on.
IL DLLs are doing this all for you, without much coding effort from your side, but they rely heavily on the dbc settings and attributes you have linked as database to your CAN Channel.
Unfortunately, they don't play well together, meaning you need advanced CANoe know-how of them to use both in the same environment. You basically bypassed your CANOEILNLVECTOR.dlls working by sending explicit message.
So your code if you are accessing your signal through IL, should look like this:
variables
{
/*no need to define custom message object, they are already "known" to IL by dbc*/
}
on start
{
$Batt_msg::Isolation_Signal = 0x02; //0x02:On
/*NO need for output either (IF YOUR MESSAGE IS defined Cyclic in dbc), */
}
If your signal is not identified at $Batt_msg::Isolation_Signal, just dragndrop the signal from the CAPL browsers Symbols panel, and add the $ sign before it.
Through dollar($) sign, you access the dbsignal class objects signal value attribute.
For an iOS app I am working on, I need to fetch messages in descending order i.e the latest message comes first, followed by second newest message etc.
From looking at other SO answers and research it seems that the best approach for my situation is to create a negative timestamp and then persist that to the database as an extra property to messages.
I will then use queryOrderedByChild('negativeTimestamp') to fetch the messages in a observeSingleEvent and then have a childAdded observer to handle messages which are sent once initial calls are made.
In the firebase documentation it says I can get the server timestamp value from this snippet of code firebase.database.ServerValue.TIMESTAMP
How do I write this for Swift 3?
First, see the linked answer in the comments. That answer relies on the client to generate a timestamp that's made negative and written to Firebase.
If you want to have Firebase generate a timestamp, that can be done as well with this little snappy Firebase structure and piece of code.
First, let's take a look at the structure
root
parent_node
-Y8j8a8jsjd0adas
time_stamp: -1492030228007
timestamp: 1492030228007
Next, some code to create and work with that structure:
Define a var we can use within our class that references the Firebase time stamp
let kFirebaseServerValueTimestamp = [".sv":"timestamp"]
and a function that adds an observer to the timestamp node:
func attachObserver() {
let timestampRef = self.ref.child("timestamp")
let parentNodeRef = self.ref.child("parent_node")
var count = 0
timestampRef.observe(.value, with: { snapshot in
if snapshot.exists() {
count += 1
if count > 1 {
let ts = snapshot.value as! Int
let neg_ts = -ts
let childNodeRef = parentNodeRef.childByAutoId()
let childRef = childNodeRef.child("time_stamp")
childRef.setValue(neg_ts)
count = 0
}
}
})
And a function that writes out a timestamp, therefore causing the observer to fire which creates child nodes within the parent_node based on the Firebase time stamp
func doTimestamp() {
let timestampRef = self.ref.child("timestamp")
timestampRef.setValue(kFirebaseServerValueTimestamp)
}
Here's the rundown.
In the attachObserver function, we attach an observer to the timestamp node - that node may or may not exist but if it doesn't it will be created - read on. The code in the closure is called any time an event occurs in the timestamp node.
When the doTimestamp function is called, it creates and writes a timestamp to the timestamp node, which then fires the observer we attached in attachObserver.
The code in the observe closure does the following:
Make sure the snapshot contains something, and if it does, increment a counter (more on that in a bit). If the counter is greater than 1 get the timestamp as an integer from the snapshot. Then, create it's negative and write it back out to Firebase as a child of parent_node.
How this would apply would be anytime you want to timestamp a child node with a Firebase generated timestamp but negative value for reverse loading/sorting - which speaks to the OP question.
The gotcha here is that when this happens
timestampRef.setValue(kFirebaseServerValueTimestamp)
It actually writes twice to the node, which would cause the code in the closer to be called twice.
Maybe a Firebaser can explain that, but we need to ignore the first event and capture the second, which is the actual timestamp.
So the first event will cause the observer closer to fire, making count = 1, which will be ignored due to the if statement.
Then the second event fires, which contains the actual timestamp, and that's what we use to make negative and write out to Firebase.
Hope this helps the OP and the commenters.
Regardless whether it's for Swift or not, another conceptual solution is to rely on Firebase's server time offset value.
It's not as precise as firebase.database.ServerValue.TIMESTAMP, but the difference is usually within milliseconds. The advantage is that it lets you create a negative timestamp on the client without having to update your Firebase node twice.
You grab the server time offset value when you need it from Firebase, generate the negative timestamp on the client, and then save your object in Firebase once.
See:
https://groups.google.com/forum/#!topic/firebase-talk/EXMbZmyGWgE
https://firebase.google.com/docs/database/ios/offline-capabilities#clock-skew (for iOS).
https://firebase.google.com/docs/database/web/offline-capabilities#clock-skew (for web).
var offsetRef = firebase.database().ref(".info/serverTimeOffset");
offsetRef.on("value", function(snap) {
var offset = snap.val();
var negativeTimestamp = (new Date().getTime() + offset) * -1;
});
How would I enable my EA to send a notification only once to my iPhone when the else if (ClosePosition == false) condition returns true (in other words, when my EA fails to close an EA-opened position). At the moment, it pings on every tick.
The ClosePositionboolean for the OrderClose() function returns true when the EA successfully closes the position when the conditions specified are met. It returns ClosePosition == false when the EA fails to close the position.
Here is my code so far
else if(ClosePosition == false)
{
int failedClosePosition = OrdersTotal()-1;
bool fail = OrderSelect(failedClosePosition,SELECT_BY_POS,MODE_TRADES);
if(fail == true)
{
SendNotification("Order Number #"+IntegerToString(OrderTicket(),10)+" has failed to close. Please refer to error code "+IntegerToString(GetLastError()));
}
}
Without any context to the real solution ( ref. your other post's broader view ),the repetitively detected reasons to send a notification ought be locked-out by a first occasion such a notification was sent ( imagine an array of notifications positively sent to:
int ArrayOfNotificationsAlreadySENT[][3]; //[ <OrderTicketNUMBER>,
// <Notification_E.164_TargetNUMBER>,
// <TimeStampSECONDS>
// ],
storing an OrderTicket() number as a UUID of such "trouble-maker" )
For problems, where a repetitive detection takes place, may want to extend the definition and add a fourth column, where you update an amount of trouble detections for each respective UUID, and (as common) probably using some fallback policy to reduce the flow of messages according to some reasonable re-notification "distances" from on-first-detected to on-2nd-detect() to on-5th-detect() to on-10th-detect() to on-100th-detect() depending on your feasible trouble-context and business-acceptable density of re-notifications