RX configuration
To configure an RX-PDO, three object categories in the object dictionary must be taken into account:
1-The objects that describe the functionality of the mapping.
2-The objects that describe the content of the mapping.
3-The objects that are to receive the received data. Configuration of the functionality (communication parameter)
The configuration of the first mapping is stored in the subindices of object 1400h. The second mapping is configured in 1401h and so on. In the following, we refer to 140Nh. Here, the configuration affects the COB-ID of the PDO message and the transfer type.
Objects 140Nh have only three subindices:
Subindex 0 (max. subindex): Total number of subindices
Subindex 1 (COB-ID): The COB-ID is stored here. For PDO mappings 1–4 (1600h–1603h), the CAN-ID is fixed depending on the node-ID and only the valid bit (bit 31) can be set in the COB-ID. From 1604h–1607h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table at the start of chapter CANopen services) as can the valid bit. The change of a COB-ID does not take effect until after the controller or communication is restarted
enter image description here
According to the above content, where is object 140N in the Object Dictionary? And how should we communicate with it?
Related
I have an Indy custom TCP Server and when I create the object I pass some string parameters (like name, password...) that are stored in the private section of the class. This is the only time when those fields are writen to (before I start the server). Every write makes a new copy of the string, not pass the reference, to be sure that those strings belongs only to this object. Now, after I start the server and receive some connections, it is safe to read those string fields in those new threads without adding some critical sections ? The values won't change in the time when that server is active...
I'm learning the new Contact Tracing API that Apple is releasing for iOS (in partnership with Google).
I'm not gasping the relationship of the maxKeyCount property on the CTExposureDetectionSession, and its relationship with the addPositiveDiagnosisKeys: completion: method.
What I understand
A CTExposureDetectionSession is the object that allows an app to ask the framework to start trying to match a list of published Diagnosis Keys against the local database of captured Rolling Proximity Identifiers.
The app would start by calling the activateWithCompletion: method on a new session, and then call addPositiveDiagnosisKeys: one or more times, to eventually inform the framework that no more keys are to be added by calling finishedPositiveDiagnosisKeysWithCompletion:.
That last call will also indicate the block to run upon detection completion, which will be called with a CTExposureDetectionSummary object informing the amount of Diagnosis Keys that the device has been exposed to.
What I do not understand
The maxKeyCount property doc says:
This property contains the maximum number of keys to provide to this API at once. This property’s value updates after each operation complete and before the completion handler is invoked. Use this property to throttle key downloads to avoid excessive buffering of keys in memory.
But the addPositiveDiagnosisKeys: method says:
Asynchronously adds the specified keys to the session to allow them to be checked for exposure. Each call to this method must include more keys than specified by the current value of <maxKeyCount>.
maxKeyCount seems to be a maximum, but the addPositiveDiagnosisKeys: requires me to call it with more keys than the maximum.
Am I expected to call the method with a superlist of the previously sent list? That doesn't seem to fit well with the "avoid excessive buffering of keys in memory" part - if I have to use an ever-growing list of keys.
And what does the This property’s value updates after each operation complete part?
The documentation of maxKeyCount is missing a not.
The Android Contact Tracing API documentation has an analogous interface:
/**
* Provides a list of diagnosis keys for contact checking. The keys are to be
* provided by a centralized service (e.g. synced from the server).
*
* When invoked after the requestProvideDiagnosisKeys callback, this triggers a * recalculation of contact status which can be obtained via hasContact()
* after the calculation has finished. *
* Should be called with a maximum of N keys at a time. */
Task<Status> provideDiagnosisKeys(List<DailyTracingKey> keys);
/**
* The maximum number of keys to pass into provideDiagnosisKeys at any given * time.
*/
int getMaxDiagnosisKeys();
As Paulw11 suggested in a comment, the maxKeyCount property seems to be a value intended for reading that stats how many Diagnosis Keys are to be sent to the API in a single call for the matching to be performed.
Callers should re-check the value before each call, since it may get updated after each call.
The fixed documentation of addPositiveDiagnosisKeys: should, then, read:
Each call to this method must NOT include more keys than specified by the current value of <maxKeyCount>.
I have created a entity called #USER-NAME and have set that as a requirement.
Now, for the first time when the entity is detected in the conversation - say, "I am John" , then the memory is set to John. On subsequent encounter of the same entity with different value - "I am Dave", the memory remains unchanged.
I have seen the edit memory option, which provides 1. reset memory 2. set to a value . For the option 2, it does not provide a way to set to the value of #USER-NAME, instead only provides option to enter static values.
How can I update the memory every time the value of the entity changes ??
EDIT
Hi, I am attaching some screenshots to show what's exactly going wrong.
I have a Entity named '#USER_NAME' that saves the user name in a memory variable .
I make the following conversation -
The JSON payload after the conversation is as follows. This works perfectly-
I update the conversation again by providing a new user name.
This triggers the entity just fine. You can see the entity being detected properly.
However, the memory value remains the same.
What I wanted was the memory variable to replace 'Dev' with 'John'.
Remember that:
memory <> Intent
You can set memory in the message section or update automatically using for example a requirement in this case every time the skill is trigged it will replace the value in the memory ID
EDIT: Because the set memory field expect a JSON you can't use memory as you want, but if you reset that memory ID shomewhere relevant in the chat (in my sample I delete it right after saying Hi XXX) so when the skill is trigged again it will "replace" it with the new value
In the Requirement I set the golden entity #Person to variable "name" and if is missing I ask her name.
Sample Image
the memory is a persistent object so if you want to reset it you need either to have specific conditions within the builder or go through a webhook to have a backend code to reste the memory.
I was trying to write a smart contract that would use the same key name(the name of the person whose details I am storing) multiple times and want all of the entries made for that key-name to be output when querying for the name.
Is it possible on to do so on hyperledger? If yes, then how would you write the query function If not could you recommend an alternate method to achieve the same result?
I am new to hyperledger and have no idea how to proceed considering I didnt see any examples of chaincode similar to this.
What you need to do is to encode the value into JSON format and store it marshaled for the given key, for example you can define a struct with a slice, update/append slice each time with new value, marshal to byte array and then save into ledger.
Each update you read the byte array from the ledger unmarshal it back to struct, update with required information and save back with same key.
To retrieve history of changes you can use one of the methods from ChaincodeStubInterface
// Chaincode interface must be implemented by all chaincodes. The fabric runs
// the transactions by calling these functions as specified.
type ChaincodeStubInterface interface {
// Other methods omitted
// GetHistoryForKey returns a history of key values across time.
// For each historic key update, the historic value and associated
// transaction id and timestamp are returned. The timestamp is the
// timestamp provided by the client in the proposal header.
// GetHistoryForKey requires peer configuration
// core.ledger.history.enableHistoryDatabase to be true.
// The query is NOT re-executed during validation phase, phantom reads are
// not detected. That is, other committed transactions may have updated
// the key concurrently, impacting the result set, and this would not be
// detected at validation/commit time. Applications susceptible to this
// should therefore not use GetHistoryForKey as part of transactions that
// update ledger, and should limit use to read-only chaincode operations.
GetHistoryForKey(key string) (HistoryQueryIteratorInterface, error)
}
I am implementing a custom NSIncrementalStore subclass which uses a relational database for persistent storage. One of the things that I still struggle with is the support for optimistic locking.
(feel free to skip this lengthy description right to my question below)
I analyzed how Core Data's SQLite incremental store approaches this problem by examining SQL logs produced by it and came up with following conclusions:
Each entity table in the database has a Z_OPT column which indicates the number of times a particular instance of this entity (row) has been modified, starting from 1 (initial insertion).
Each time a managed object is modified, Z_OPT value in its corresponding database row is incremented.
The store maintains cache (referred to as row cache in Core Data docs) of NSIncrementalStoreNode instances, each having a version property equal to Z_OPT value returned by previous SELECT or UPDATE SQL query on managed object's row.
When a managed object is returned from NSManagedObjectContext (e.g. by executing NSFetchRequest on it), MOC creates snapshot of this object which contains this version number.
When the object is modified or deleted, Core Data makes sure that it has not been modified or deleted outside the context by comparing versions of cached row and object snapshot. All of this happen when -save: is called on the context that the object belongs to. If the versions are different then a merge conflict is detected and handled based on set merging policy.
When MOC is being saved, the -newValuesForObjectWithID:withContext:error: method is called for each modified/deleted object which in turn returns NSIncrementalStoreNode with version number. This version is then compared to snapshot's version and if they are different, the save fails with appropriate merge conflicts (at least with default merge policy).
This simple use case works properly with my store since -newValuesForObjectWithID:withContext:error: checks the row cache first which is enough if the object was concurrently modified in other context using the same store instance. If this is the case, then the cache contains updated row with higher version number which is enough to detect a conflict.
But how can I detect than the underlying database has been modified outside my store, possibly by other application or other store instance using the same database file? I know this is an unfrequent edge case but Core Data handles it properly and I would prefer to do the same.
Core Data's store uses SQL queries like these to update/delete object's row:
UPDATE ZFOO SET Z_OPT=Y, (...) WHERE (...) AND Z_OPT=X
DELETE FROM ZFOO WHERE (...) AND Z_OPT=X
where:
X - version number last known to the store (from cache)
Y - new version number
If such a query fails (no rows affected) the row is updated in store's cache and its version compared against the one previously cached.
My question is: how can a custom NSIncrementalStore inform Core Data that optimistic locking failure has occurred for some updated/deleted/locked objects? It is only the store that is able to tell that when it handles NSSaveChangesRequest passed to it its -executeRequest:withContext:error: method.
If the underlying database does not change under the store, then conflicts are detected since Core Data calls -newValuesForObjectWithID:withContext:error: on each modified/deleted/locked object prior to executing save changes request on the store. I was not able to find any way for NSIncrementalStore to inform Core Data that an optimistic locking failure has occurred after it started to handle the save request. Is there some undocumented way to do that? Core Data seems to throw some exception in that case which is then magically translated into failed save request with NSError listing all the conflicts. I am only able to mimic that partly by returning nil from -executeRequest:withContext:error: and creating the error message by myself. I think there must be a way to use the standard Core Data conflict handling mechanism in this scenario as well.
I realize that this is not an answer to you question, but I will try and give you my point of view on CoreData and correlation to Databases:
(1st level cache)
NSPesistentStoreCoordinator + NSPersistentStore == A single connection to the database
(2nd level cache)
NSManagedObjectContext == cache over the connection holding changes
So, to my understanding your issue is that you have multiple connections to your store, each making changes, but you have no central version control over your records.
Your store will receive a -executeRequest:withContext:error: with NSSaveRequestType
You will then be responsible to verify that the record versions match, if you find a conflict in the connection level (level 1) you report version mismatch between the context (level 2) and the coordinator.
you need to report version missmatch between your connection (level 1) and your store.
To be able to do this your store must report changes on it across all connections to it (ConnectionManager), or it might offer hooks to changes performed on it.
I'm no SQLite expert, but the SQLite API does have something to offer in that area:
update hook
commit hook
changes
total changes
(I have no experience in setting these kind of hooks, but if CoreData use them it will not show in the debug logs)
you can report these errors by setting the error pointer (NSError**) and setting its internal data to match the one that CoreData coordinator is setting (create merge conflict and set the information in them as needed)
Note that optimistic locking failure will only occur during -executeRequest:withContext:error:
(unless you have a rogue connection to the store, one that is not tracked by the manager.
To support this behaviour your manager might need to verify each record as it is committed for a save [huge performance cost] , or use some hooks into the changes recently made to records
)
To handle multiple connections to your store you might need to have a shared cache of NSIncrementalStoreNode, keyed by the store url:
static #{
url1 : actualCacheMapping1,
url2 : actualCacheMapping2,
...
}
each connection save to the store will be verified agains the store url actual cache.
Hope this make some sense for you.
My question is: how can a custom NSIncrementalStore inform Core Data that optimistic locking failure has occurred for some updated/deleted/locked objects? It is only the store that is able to tell that when it handles NSSaveChangesRequest passed to it its -executeRequest:withContext:error: method.
In an NSIncrementalStore, NSIncrementalStoreNodes represent the store snapshots. The version property of the node is the optimistic locking primitive. The persistent store is responsible for detecting optimistic locking failures in at the store level, while the managed object context can detect them higher up. An optimistic locking failure at the store level might happen if the system the store is talking to was changed by something else, and there is a conflict between that system's state and that representation of state in the persistent store. For example, if the store was communicating with a web service and the web service data was changed by another user, etc.
If an optimistic locking failure is detected in your store implementation during a save, your store is responsible for creating NSMergeConflict objects describing it. These will be propagated up by the NSPersistentStoreCoordinator.
[[NSMergeConflict alloc] initWithSource:managedObject newVersion:newVersion oldVersion:oldVersion cachedSnapshot:inMemorySnapshot persistedSnapshot:storedSnapshot];
Snapshot dictionaries should include all modelled attribute property names as keys along with their values. This does not include relationships. For some stores, using the values from the reference objects or NSIncrementalStoreNodes may suffice as long as they only include the modelled attribute property name as keys (and those are easy to get from the entity description).
Once these objects have been created, create an NSError in the NSCocoaErrorDomain with the code NSPersistentStoreSaveConflictsError. The userInfo object should contain the key NSPersistentStoreSaveConflictsErrorKey which should contain an array of the NSMergeConflict objects. Return that from the save request, and the NSPersistentStoreCoordinator will be responsible for finding resolution. Rememeber, you should not generate merge conflicts for conflicts between the state of objects in the NSManagedObjectContext and your store, only for conflicts between whatever in-memory or cached state in your store and where ever the data is kept or persisted (like a web service, or database, etc.)