May i use 997 acknowledgement file in place of 865 acknowledgement
file for clients in respect of receive 860 file not 850 file. I think that is dependent on cutomer what they want.
What are differences between 865 and 997 Acknowledgement ?
The 997 is just confirmation (receipt) of the interchange (or group of documents). This is a STANDARD document that allows you to determine delivery. This was put in place before the communication protocols were robust enough to tell if a transmission failed (think bisynchronous modems). So for every group of documents you send in an interchange, you should receive a 997. You should be able to write reports on which groups / interchanges have not been acknowledged as received. If you receive a document, you should send the 997 back.
The 865 is a BUSINESS document. It is far more detailed. Plus the 865 is the RESPONSE to the 860 document. Just like the 855 is the response to the 850.
If you receive an 850, you send a 997. Then you would ALSO send the 855 (if partner requires).
If you receive the 860 (changing the initial PO), you would send the 997 confirming receipt. You would ALSO send the 865.
Translators handle the 997. Rarely do they get integrated in the ERP. The 855/865 would get integrated, as business decisions get made from them.
The 997 only serves as a receipt that the transmission was received, not that it was accepted. Source.
Whereas the 865 is used to acknowledge that you accept (or reject) the changes to the purchase order. Source
The difference is that if you just send a 997 instead of the 865, you are simply telling your partner that you received the transmission. You are not giving them any indication on whether or not you can meet requirements of the change. You would need to talk to your partner on whether this is acceptable or not and what their expectations are in the case that you can not meet the changes.
Related
I am working on CANopen architecture and had three questions:
1- When the 'synchronous window' is closed until the next SYNC message, should we send the SDO message? Can we not send a message during this period?
2- Is it possible not to send the PDO message during the simultaneous window?
3- What is the answer that the slaves give in the SYNC message?
Disclaimer: I don't have exact answers but I just wanted to share my assumptions & thoughts.
CiA 301 doesn't mention the relation between synchronous window and SDOs. In normal operation after the initial configuration, one may assume that SDOs aren't present on the system, or at least they are rare compared to PDOs. Although not strictly necessary, SDOs are generally initiated by a device which has the master role, and that device also produces the SYNC messages (again, it's not strictly necessary but it's the usual/common implementation). So, the master device may adjust the timing of SDO requests according to the synchronous window.
Here is a quote from CiA 301:
If the synchronous window length expires all synchronous TPDOs may be
discarded and an EMCY message may be transmitted; all synchronous
RPDOs may be discarded until the next SYNC message is received.
Synchronous RPDO processing is resumed with the next SYNC message.
CiA 301 uses the word "may" (see the quote above). So I'm not sure if it's mandatory or not. In my opinion, it makes sense to follow the advice and abort synchronous TPDO transmissions after the synchronous window and send an EMCY message. Event-driven (non-synchronous) TPDOs can be sent within or after the synchronous window.
There is no direct response to SYNC messages. On SYNC reception, SYNC consumers (slaves) sample their inputs, drive their outputs according to the previous RPDOs, and start transmitting their TPDOs containing the previous samples (or the current ones? I'm not sure about this).
Synchronous windows are for specific PDO synchronization only. For hard real-time systems, data might be required to arrive within certain fixed time intervals - not too early, not too late. That is, it acts as a real-time deadline. If such features are enabled, you need to take that in consideration when doing the specific CANopen bus implementation.
For example if some SDO communication would occupy the bus so that the PDO can't meet its time window, that would be a problem. But this is easily solved by giving the PDO a lower COBID than the SDO, which should already be the case in most default device profile setups like "DS401 GPIO module". Other than that, you would have to make sure there is no ridiculous bus loads or that nodes hang up or get busy doing other things.
In systems with hard real-time requirements you probably don't want to allow any SDO communication during operational mode to begin with.
What is the answer that the slaves give in the SYNC message?
That question doesn't make any sense. You need to study what the SYNC message does and what it is for.
What I'm looking to do is request all desired PIDs via a .dbc file made in Vector db Editor++.
I understand enough about CAN communication to be able to do this with 1 or 2 PIDs because the DLC allows up to 8 bytes of data per CAN message. I am also familiar with this resource on querying and responses of PID https://en.wikipedia.org/wiki/OBD-II_PIDs#CAN_.2811-bit.29_bus_format
What I'm having trouble understanding is how diagnostic tools are able to query every PID the manufacturer of a particular vehicle decides to make available, so I feel that this is possible. Yet, if I use a request ID of $7DF, I can only use this message ID alone for my querying, this is the reason why I currently can only fit two PIDs (signals) in that CAN message.
How diagnostic tools are able to query every PID the manufacturer of a particular vehicle decides to make available?
You cannot request whatever you want from ECU (at least in a normal way!). Only the OBD relevant PIDs you can request. All the OBD II PIDs and their definitions, scaling and etc. are available within ISO 15031 part 5. It means that all the PIDs are predefined. So any logger would firstly request mode 01 pid 00 to get all the available PIDs for that vehicle and then starts to scan over it.
if I use a request ID of $7DF, I can only use this message ID alone for my querying.
This is wrong cause 0x7DF has nothing to do with DLC and content of the message. It is only the header of message to tell the ECU from whom you have this request. 0x7DF is the OBD requests and even you can directly request different controllers their available data.
Every can message is 8 byte long. First byte is the mode of the request. Second byte tells the ECU the number of incoming bytes and then you have 6 bytes to send. Because of that they say you can request up to 6 PIDs simultaneously. your problem might be receiving multiple data from OBD which might be a bit tricky using Flow Control and First Frame messages. Here you can find some info about how to receive a message when it is longer that 8 bytes.
regards,
I'm looking into MQTT v3.1.1 and have the this question:
Can I safely assume that in a connection(no reconnect), the sender/receiver
wouldn't see the next control packet for the same message identifier before sending/seeing the acknowledgement?
More precisely, I'm concerned about the following two cases.
In both cases, I assume:
The whole conversation remains in the same connection(no reconnect).
All PUBLISH#N share the same message identifier.
I think the re-sent copies of control packets probably don't fit in the
description of 4.4 Message delivery retry as there's no reconnect. Please
correct me if I'm wrong.
For QoS 1, I'm not sure about PUBLISH#B which comes in before sending PUBBACK.
Likewise, for QoS 2, I'm not sure about PUBLISH#2 which comes in before sending
PUBREC and PUBLISH#3 which comes in before seeing PUBREL.
Or, I can safely assume this situation should not happen so as it did
happen then I can ignore those re-sent packets?
After reading some implementations and reflecting on this question for a while, I think I might be able to answer it by myself.
The key here is that a connection/socket-pair is duplex, meaning that the writing stream and the reading stream are independent and there's no way that content in one stream blocks that in another unless the application logic enforces such order.
A paranoid sender may write consecutive PUBLISHs without waiting for PUBBACKs, but a receiver that respects the specification is rightly to only fetch one from the TCP buffer, acknowledge a PUBBACK, then fetch and acknowledge another one.
Therefore, in the case in Fig 1, PUBLISH#B in the eyes of the receiver is just another PUBLISH and is processed after sending PUBACK#A.
In the case in Fig 2, the receiver responded PUBLISH#1 with PUBREC#1, then it tries to read a PUBREL but will instead find PUBLISH#2 in the buffer, in that situation, the specification states:
Until it has received the corresponding PUBREL packet, the Receiver
MUST acknowledge any subsequent PUBLISH packet with the same Packet
Identifier by sending a PUBREC. It MUST NOT cause duplicate messages
to be delivered to any onward recipients in this case.
MQTT QOS acknowledgements are NOT end to end. They are between the publisher and the broker and then again separately between the broker and the subscriber.
There is no End to End delivery notifications in MQTT as there is no way for a publisher to know if there are 0, 1 or n subscribers to a given topic.
I'm working on application which connects OBD2 adapter and getting the real time data like speed,rpm,throttle position etc..When I read one command at a time, it works fine like by sending command "010C\r", I get current RPM.
I think that sending multiple commands in one request is not possible.But in other applications like EngineLink HD ,Dashcommand, we found that multiple components are updated at a time like if we are driving the car and check the RPM,Sped and Throttle then they are updating at every 1 second. It looks like real time data.
I'm surprised that how is it possible ?
We have added code like if user wants to show 3 components, then for every component, one thread is generated and it handles request and response of that command. So in this case , 3 threads are generated and we get response but it takes too much time like if we are watching on Speed out of 3 PIDs then speed is updated after 3-4 seconds delay.
We also need to lock the code where it sends the request and get response bcoz OBD2 adapter handles one request and response at a time.
And if we don't lock the code then we get unpredicted results which might be due to common shared stream used by socket communication between the application and obd2 adapter.
But now I want to read multiple commands at a time.
I mean at a point of time, I want to know speed,RPM and throttle position etc..So I want to send above commands in one request and get a response at a time.
How is it possible ? Someone can guide me.
First of all, I don't think you need 3 threads for this. As you said, OBD-II can only handle 1 command at a time, so you can do with 1 thread, that knows which requests it has to make every second.
Simply said, you cannot read multiple commands at a single time. As you've said, you experience some delay. The OBD-II default settings are responsible for this. The default waiting time, (as far as I can recognize) 200 ms. So you can only send 5 commands each second. This is somewhat slow, and some applications manage to get 20 request each second.
You can do this by sending an extra number (number x) at the end of your command. The OBD-II device will wait for x responses from devices in the car. So when you send '010D1', it will wait till 1 answer comes in, and it will directly send it back to you. Then it's easibly possible to handle a command in 50ms or maybe even less.
So that's how that application looks like it requests data 'at the same time'. They can also use some trick to wait till all data is collected, and then display it.
I hope I answered all your questions, otherwise ask some more.
EDIT:
Also for the succesfull commands, this standard time is taken. This is because some commands can have 2 sources which report the same data. For example, the speedometer, and a gps module can both measure the speed. If both are connected to the OBD-II bus, then you will get 2 answers.
With '010D', it will wait 200ms and then report all answers. With '010D1', it will send back the first answer directly when it has 1 answer.
The ELM327 datasheet gives the following information on page 45:
Multiple PID Requests
The SAE J1979 (ISO 15031-5) standard allows
requesting multiple PIDs with one message, but only if
you connect to the vehicle with CAN (ISO 15765-4).
Up to six parameters may be requested at once, and
the reply is one message that contains all of the
responses.
For example, let us say that you need to know
engine load (04), engine coolant temperature (05),
manifold pressure (0B), and engine rpm (0C) on a
regular basis. You could send four separate requests
for them (01 04, then 01 05, then 01 0B, etc.) or you
could put them all into one message like this:
01 04 05 0B 0C
to which, a typical reply might be:
00A
0: 41 04 3F 05 44 0B
1: 21 0C 17 B8 00 00 00
I got a problem when using NSInputStream.
I have client app which connect to a server then server will start to send message to my client app through TCP repeatedly about 1 message per second. Server is just broadcasting message to client and message is xml format. The server send a message as one packet.
Now the problem is that when I read byte from NSInputStream the data got truncated which mean instead of receive 1 complete message, I got 2 separate data(partial xml) respond from time to time. I am not able to debug because it already happen when I read data byte from NSInputStream.
I use Wireshark to analyse every packet I receive and when it happen data got truncated too, because TCP so partial data retransmit to my client.
I have tried to log every partial data byte, the sum of partial data always around 1600 byte.
I have no idea how did they design and implement server side, but I do know there are many of people connect to that server and continuous get broadcasting message from it.
Does anyone encounter this problem? Can anyone help? Is it possible that data is over the max size and get splited?
This is not a problem per se. It is part of the design of TCP and also of NSInputStream. You may receive partial messages. It's your job to deal with that fact, wait until you receive a full message, and then process the completed message.
1600 bytes is a little strange. I would expect 1500 bytes, since that's the largest legal Ethernet packet (or especially somewhere around 1472, which is a really common MTU, minus some for the headers). Or I might expect a multiple of 1k or 4k due to buffering in NSInputStream. But none of that matters. You have to deal with the fact that you will not get messages necessarily at their boundaries.